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ABSTRACT 


The  Communications  Data  Base  (COB)  has  been  developed  by  the  Signal 
Center  (SIGCEN)  to  be  used  as  an  analytical  tool  supporting  various  studies  and 
analysis  applications,  both  automated  and  manual.  The  COB  describes  mission 
essential  communications  requirements  for  a  set  of  organizations  notionally 
comprising  a  U  S.  Theater  in  a  North  Atlantic  Treaty  Organization  (NATO) 
environment. 

Communications  requirements  residing  in  the  CDB  are  expressed  in  terms  of 
needlines.  A  needline  is  a  set  of  related  data  elements  describing  a  need  to 
exchange  information  between  two  or  more  battlefield  communicators.  A 
needline  exists  independent  of  capability.  That  is,  a  needline  can  exist  between  two 
communicators  even  if  they  do  not  possess  an  electronic  means  to  pass  the 
information. 

The  INTRODUCTION  to  this  report  discusses  the  reasons  for  developing  the 
CDB  and  why  such  an  analytical  tool  is  so  important  to  the  Signal  Center  and  the 
Army.  The  BACKGROUND  section  includes  a  brief  of  some  of  the  earlier  attempts  to 
quantify  communications  requirements  data,  a  discussion  of  the  reasons  these 
efforts  did  not  endure,  as  well  as  a  look  at  CDB  strategy  aimed  at  overcoming  these 
difficulties.  The  BACKGROUND  section  also  includes  an  important  discussion  of  the 
CDB  in  its  relationship  to  the  Network  Assessment  Model  (NAM)  and  the 
Operational  Facility  (OPFAC)  Data  Base  as  essential  elements  of  the  Signal  Center’s 
analytical  arsenal. 

The  METHODOLOGY  section  of  the  report  provides  a  detailed  explanation  of 
the  CDB,  its  elements,  how  it  was  built,  and  how  it  was  verified/validated.  The 
SUMMARY  AND  RECOMMENDATIONS  Section  provides  some  recommendations 
considered  vital  to  the  long  term  usefulness  of  the  data  base. 


The  CDB  has  been  developed,  in  phases,  during  the  period  1986  through  the 
present.  As  development  of  the  several  phases  of  the  data  base  has  progressed, 
some  modifications  to  developmental  methodology,  procedures,  3nd  software  have 
occurred.  This  report  will  not  address  the  entire  developmental  history  of  all  phases 
of  the  data  base,  but  will  attempt  to  provide  a  summarization  of  the  need  for  the 
data  base  and  the  processes  employed  to  satisfy  that  need. 
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1.  INTRODUCTION 


How  does  the  Army  make  a  multi-billion  dollar  decision  to  buy  a  new 
communications  system  to  support  the  tactical  force?  How  does  the  Department  of 
Defense  decide  to  support  the  request  and  how  do  they  articulate  the  need  for  such 
a  system  to  the  Executive  and  Legislative  Branches  so  that  budgets  and 
appropriations  support  the  new  system?  These  questions  are  at  the  heart  of  the 
reasons  for  the  development  and  maintenance  of  a  credible  communications  and 
automation  network  modeling  capability  at  the  Signal  Center. 

Why  does  the  Army  need  a  new  tactical  communications  system?  Does  the 
old  system  satisfy  the  "requirements"?  Does  the  proposed  new  system  satisfy  the 
"requirements"?  What  are  the  "requirements"?  These  are  the  questions  asked  by 
staffers  and  decision  makers  as  part  of  the  process  leading  to  the  decision  to 
recommend  or  support  funding  for  a  new  system.  These  are  good  and  valid 
questions.  Unfortunately,  the  answers  are  not  easily  obtained.  Unlike  weapons 
systems,  combat  'ehicles,  and  other  hardware  developments  and  acquisitions, 
tactical  communications  requirements  are  difficult  to  quantify  and  rationalize. 
Hard  statistics  and  threat  capability  data  are  available  to  support  the  decision 
making  process  for  most  hardware  developments  and  acquisitions.  Similarly 
straightforward,  factual,  statistically  supportable  data  has  traditionally  not  been 
available  to  support  the  decision  making  process  for  communications  and 
automation  systems.  Decision  makers  are  uncomfortable  deciding  such  issues  based 
upon  someone's  intuition  or  personal  beliefs.  They  want  firm  recommendations 
supported  by  credible  analysis  and  statements  of  fact,  not  vacillating  opinions. 

TRADOC  is  the  Army  s  Combat  Developer.  The  Signal  Center  is  responsible  to 
TRADOC  for  Combat  Developments  for  tactical  communications  and  automation,  as 


well  as  for  the  broader  Theater/Tactical  level  of  the  Information  Mission  Area.  The 
Combat  Developments  process  is  logical  and  well  defined.  At  the  heart  of  that 
process  is  the  analysis  of  mission  area  battlefield  deficiencies,  concept  formulation, 
and  requirements  generation  and  articulation.  The  Signal  Center  has  long  needed  a 
comprehensive,  credible  analytical  capability  to  support  the  Combat  Developments 
process.  The  Communications  Data  Base  is  an  essential  element  of  that  capability. 
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2.  BACKGROUND 


The  CDS  is  the  latest  in  a  series  of  efforts  aimed  at  quantifying  battlefield 
communications  requirements.  The  ability  to  accurately  quantify  such  requirements 
is  vital  to  the  Signal  Center  Combat  Developer  because  of  his  responsibility  to  assess 
the  capabilities  of  fielded  and  developmental  systems  to  meet  the  needs  of  tactical 
army  units  and  organizations.  This  assessment  cannot  be  credibly  accomplished 
without  the  ability  to  compare  the  capability  of  the  system(s)  to  the  requirements  of 
the  user(s).  The  requirements  of  the  user(s)  are  the  purview  of  the  CDB. 

Numerous  efforts  have  preceded  the  CDB.  The  Communications  Support 
Requirements  (COMSR)  data  base  of  the  seventies  is  perhaps  the  most  notable.  This 
data  base,  structured  much  like  the  CDB,  was  designed  and  maintained  by  the 
SIGCEN,  and  built  with  input  directly  from  proponent  project  officers.  COMSR  was 
used  for  a  variety  of  studies  and  analyses,  including  at  least  one  Mission  Area 
Analysis  (MAA).  The  data  base  was  criticized,  rightly  or  wrongly,  for  being  an 
overstatement  of  the  "mission  essential"  communications  requirements.  COMSR 
fell  into  disuse  in  the  early  1980s.  Other  efforts  include  the  Data  Distribution  (D2) 
Data  Base,  the  Battlefield  Command  and  Control  Systems  Review  (BC2SR),  the 
OMEGA  Study,  The  What  Rides  What  Study,  the  Why  3  Study,  and  a  host  of  others. 
Some  of  these  efforts  have  included  the  development  of  supporting  data  bases, 
others  have  been  only  studies.  All  were  worthwhile  efforts  and  were  successfully 
used  for  their  intended  purposes.  Their  scope  and  long  term  utility  was,  however, 
limited. 

In  designing  and  developing  the  CDB,  the  SIGCEN  has  endeavored  to  avoid 
those  difficulties  that  were  perceived  as  ir'jurious  to  previous  efforts.  Some  of  these 
difficulties,  along  with  the  CDB  approaches  to  overcoming  them,  are  discussed 
below: 
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2.1  SCENARIO 

Communications  requirements  can  be  developed  tor  virtually  any  scenario. 
The  more  specific  and  detailed  the  scenario,  the  more  specific  and  detailed  can  the 
needlines  be.  The  major  problem  with  developing  a  data  base  of  needlines  for  a 
particular  scenario  is  the  resultant  loss  of  flexibility  and  adaptability.  Once  tied  to  a 
specific  scenario,  a  specific  situation,  a  specific  task  organization,  mission,  and 
detailed  events,  the  data  base  becomes  irrelevant  to  any  and  all  others.  In  essence, 
if  one  chooses  the  s*enario  specific  approach  to  needline  development,  he  has  also 
made  the  decision  to  build  a  new  data  base  for  each  and  every  scenario  he  might 
want  to  examine.  Time  and  money  make  this  approach  impractical. 

The  CDB  was  not  tied  to  any  specific  scenario.  The  CDB  attempts  to  capture 
the  normal  communications  requirements  during  a  24  hour  period  of  mid-intensity 
war.  Several  r.eedline  elements  allow  the  user  to  examine  deviations  in 
communications  requirements  resulting  from  changes  in  combat  intensity,  mobility 
condition,  and  mission  (aaivity),  if  desired. 

2.2,  SUBJECTIVITY 

Each  needline  element  expresses  someone’s  opinion  of  the  value 
represented.  About  what  does  a  company  commander  need  to  talk  to  his  battalion 
commander  during  the  normal  day?  How  many  times  do  they  need  to  talk?  How 
long  do  they  talk?  What  is  the  importance  (cost  of  failure)  of  these  requirements? 
Under  which  mobility  conditions  do  these  requirements  exist?  Does  the 
requirement  change  when  conducting  river  crossing  operations?  With  whom  does 
the  company  supply  sergeant  have  a  mission  essential  need  to  communicate?  Given 
the  availability  of  both  telephones  and  radios,  which  type  of  equipment  will  be  used 
to  satisfy  these  requirements? 

Each  of  these  questions  requires  an  answer.  Whoever  answers  the 
questions  will  do  so  based  upon  his  personal  experiences  and  beliefs.  It  can  be 
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argued  that  there  aren't  any  "correct"  answers  to  the  questions;  That  no  two 
communicators  communicate  exactly  like  any  two  others;  That  specific  events, 
circumstances,  and  personalities  will  influence  communications  requirements  to 
Such  an  extent  that  precise  quantification  is  impossible.  There  are  those  who  argue 
that  the  only  way  to  accomplish  the  task  would  be  to  gather  empirical  data  by 
sending  groups  of  observers  to  a  REFORGER  or  other  major  exercise.  Others  would 
say  that  to  do  so  would  only  provide  the  requirements  for  that  particular  exercise, 
with  its  unique  events,  circumstances,  and  personalities.  How  would  these 
requirements  relate  to  any  othei  major  exercise  or  to  an  actual  war?  Would  people 
communicate  differently  if  an  observer  were  watching  than  without  one?  How 
many  observers  would  be  required  tc  gather  data  from  a  division?  A  corps?  A 
theater? 

The  use  of  a  credible,  sanctioned  data  base  to  support  a  comprehensive 
modeling  and  simulation  capability  is  the  only  practical  solution  to  the  analytical 
requirement.  To  maintain  its  credibility,  the  data  base  must  be  maintained  and 
kept  current.  As  part  of  this  maintenance  and  update  process,  provisions  should  be 
made  to  incoroorate  empirical  data  obtained  from  field  training  exercises  and 
command  post  exercises.  The  use  of  such  data  would,  over  time,  improve  the 
validity  of  the  data  base  by  providing  an  ever  increasing  number  of  samples  being 
used  as  input  sources  to  the  data  base.  One  must  be  wary,  however,  of  using  a 
single  observation  or  exercise  as  the  standard  by  which  the  data  base  is  evaluated  or 
even  modified.  Only  through  the  use  of  many  inputs,  observations,  and  proponent 
consensus  can  the  data  base  maintain  its  credibility. 

The  current  CDB  contains  over  300,000  needlines  representing  nearly  ten 
million  individual  data  elements.  Each  needline  and  each  individual  data  element  is 
somewhat  subjective  and  arguable.  Recognizing  these  controversies,  the  CDB  was 
built  through  the  application  of  a  logical,  consistent,  and  straightforward 
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development  methodology  and  has  been  reviewed  and  modified  by  the  developers, 
the  individual  branch  and  Battlefield  Functional  Area  (BFA)  proponents,  and  by 
CACDA.  While  subjective,  the  data  base  represents  the  opinions  of  those 
responsible  for  the  articulation  of  battlefield  requirements.  While  any  individual 
element  may  be  arguable,  the  Law  of  Large  Numbers  should  be  operable.  If  so,  the 
data  base  should  be  accepted  as  a  realistic  approximation  of  the  expected  "normal'* 
communications  requirements  of  a  force  engaged  in  conflict.  If  this  premise  cannot 
be  accepted,  the  development  of  a  data  base  for  use  in  communications  modeling 
and  simulation  is  probably  not  possible. 

2.3.  ADAPTABILITY 

In  an  effort  to  build  a  data  base  that  could  be  used  as  input  to  a  wide  range 
of  scenarios,  task  organizations,  and  deployment  schemes,  needlines  were  designed 
and  developed  to  accommodate  such  flexibility.  Although  needlines  were 
developed  to  capture  "normal"  requirements,  during  the  "normal"  day  of  the 
"normal"  war,  several  needline  elements  allow  for  the  articulation  of  changes  in 
communications  requirements  resulting  from  scenario-specific  qualifiers.  Each 
needline  includes  data  fields  for  Intensity,  Activity,  Mobility,  and  a  Unit  Relationship 
Code.  These  needline  elements  provide  for  variances  from  "normal" 
communications  requirements  based  upon  battlefield  dynamics  and  changes  in  unit 
missions.  The  CDB  can  be  used  to  support  a  broad  range  of  scenarios,  task 
organizations,  and  support  relationships. 

2.4  CLASSIFICATION 

Every  effort  was  made  to  construct  apd  maintain  the  CDB  as  an 
"UNCLASSIFIED"  data  base  This  was  done  in  order  that  the  data  base,  once  built, 
could  be  used  and  analyzed  for  the  widest  range  of  purposes  and  by  the  widest 
range  of  users.  No  classified  sources  were  used  to  construct  the  data  base.  The 
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SIGCEN  has  recognized,  however,  that  some  classified  appendices  may  be  required 

to  augment  the  CDB.  If  built,  these  will  be  constructed  separately  from  the  core 
data  base  to  negate  the  need  to  classify  it  in  its  entirety. 

2.5  FORCE  STRUCTURE 

The  COB  was  not  built  to  any  specific  task  organization.  To  do  so  would  have 
forever  tied  the  data  base  to  that  specific  structure.  Needlines  were  instead 
constructed  for  a  set  of  767  Standard  Requirements  Code  (SRC)  units  notionjily 
comprising  a  U  S.  Theater  in  a  NATO  environment.  From  this  set  of  SRCs  one  can 
construct  and  tailor  many  different  organizational  and  support  structures.  The  SRCs 
selected  for  inclusion  in  the  CDB  were,  in  all  cases,  the  most  current  series  residing  in 
the  Army's  T.O.&  E.  system  at  the  time  of  $?lection.  As  SRCs  change,  the  CDB  will 
have  to  be  updated  to  reflect  differences  in  communications  requirements  resulting 
from  such  organizational  changes. 

Phase  I  of  the  data  base  development  was  oriented  at  divisional  units;  Phase 
II,  corps.  Phase  III  was  aimed  at  Echelons  Above  Corps  (EAC).  Each  of  the  first  three 
phases  were  specifically  oriented  on  NATO.  Future  additions  should  include  Joint 
Readiness  Forces  and  perhaps  have  a  Southwest  Asia  orientation.  The  long  term 
intention  has  been  to  build  a  data  base  that  could  be  used  tc  support  virtually  any 
force  struaure  in  any  scenario. 

2  6  SCOPE 

The  CDB  has  been  built  to  describe  communications  requirements  for  those 
units  that  use  communications  and  automation  systems  over  which  the  SIGCEN 
exercises  Inforrrtation  Mission  Area  (IMA)  proponent  responsibility.  In  IMA  terms, 
the  CDB  is  oriented  at  the  Theater/Tactical  level  and  its  interfaces,  but  not 
specifically  at  the  Strategic  or  Sustaining  Base  levels.  Neither  is  the  CDB  designed  to 
capture  requiremenu  for  so  called  "closed  loop"  systems  -  those  that  are  designed, 
operated  and  maintained  outside  the  Signal  Center's  proponent  responsibility 
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and/or  those  exclusively  used  by  another  proponent  or  agency  which  do  not 
support  the  force  as  a  whole. 

2.7  THE  ANALYTICAL  TRIAD 

The  CDB  represents  one  leg  of  the  Signal  Center's  analytical  triad.  It  provides 
the  network  loading  requirements  data  to  the  Network  Assessment  Model  (NAM), 
the  modeling  and  simulation  leg  of  the  triad,  in  which  technical  and  operational 
characteristics  of  communications/automation  systems  and  devices  are  simulated. 
The  NAM  also  contains  user  interface  software  with  which  the  analyst  inputs 
scenario  data  and  force  stt  ucture.  The  third  leg  of  the  triad,  the  OPFAC  Data  base,  is 
required  to  establish  deployment  configurations  and  groupings  of  the  units  within 
the  force, structure  to  be  modeled.  Because  units  do  not  deploy  and  configure 
themselves  as  singular  and  isolated  entities,  their  impact  on  the  communications 
network(s)  can  only  be  realistically  modeled  if  they  are  connected  as  they  really 
denu'y.  The  OPFAC  Data  Base,  as  an  input  to  the  NAM,  provides  for  these 
deployment  configurations. 

These  three  components  -  the  CDB,  the  NAM,  and  the  OPFAC  Data  Base  are 
all  required  to  support  the  analytical  effort.  They  are  equally  important  and  must 
be  mutually  supportive.  Without  all  three,  the  analytical  capability  required  by  the 
Signal  Center  Combat  Developer  cannot  exist  (See  Figure  2.7-1). 
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THE  AN ALYTICAL TRIAD 


FIGURE  27-1.  The  Analytical  Triad 
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3.  METHODOLOGY 


3.1  TROOP  LIST 

Before  one  can  develop  communications  requirements  for  a  set  of  units,  the 
units  must  be  identified.  TBE  was  tasked,  for  each  phase  of  the  COB,  to  develop  a 
list  of  units  for  which  communications  requirements  data  (needlines)  would  be 
developed.  Tv>'o :  :irdte  troop  lists  were  constructed;  One  for  Phases  I  and  II  which 
represented  hose  units  round  at  division  and  corps,  and  one  for  Phase  III  which 
represented  units  found  at  Echelons  Above  Corps  (EAC).  In  both  cases  units  were 
identified  by  Standard  Requirements  Code  (SRC)  and  in  both  cases  the  latest 
versions/series  of  the  SRCs  available  from  the  Army's  TO&E  System  were  selected  for 
use. 

3.1.1  Troop  List  Development 

TBE  was  provided  various  studies,  doctrinal  material,  and  force  structure  data 
to  use  for  the  development  of  Troop  Lists.  TBE  analysts  reviewed  all  available 
information  and  developed  recommended  Troop  Lists  which  were  provided  to  the 
SIGCEN  for  their  review  and  approval.  In  some  cases  units/organizations  were  not 
identifiable  by  SRC  (Joint,  Allied,  and  Host  Nation  organizations  do  not.  of  course, 
reside  in  the  Army's  T.O.&E.  System).  These  organizations  were  included  in  the 
Troop  List  and  were  assigned  SRC  Numbers  beginning  with  "99".  TRADOC 
Proponents,  including  CACOA,  provided  input  to  the  Troop  List  development 
process.  Following  the  SIGCEN  review,  and  TBE  incorporating  changes  to  the  Troop 
List  that  the  SIGCEN  directed,  the  SIGCEN  approved  the  Troop  Lists,  directing  TBE  to 
proceed  with  needline  development.  Figure  3.1*1  illustrates  the  Troop  List 
Developmental  Methodology. 


3-1 


FIGURE  3.1-1.  Troop  List  Development 
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3.2 


NEEDLINE  DEVELOPMENT 


The  following  section  will  define  a  COB  needline  and  describe  the 
methodology  used  to  build  CDB  needlines.  Needlines  were  built  in  iterative  steps, 
using  the  logic  and  rationale  described  in  this  section.  Automation  was  used  to 
implement  this  logic  and  rationale.  Systems  Analysts  and  Software  Engineers 
worked  together  to  develop  the  COB.  Systems  Analysts  developed  the  logic  and 
rationale;  Software  Engineers  built  the  data  bases,  programs,  and  support  files  to 
implement  it.  Throughout  the  entire  process  both  analysts  and  software  personnel 
reviewed  the  developing  neediines,  making  whatever  changes  to  methodology 
and/or  software  were  required.  This  section  is  oriented  on  the  methodology. 
Appendix  A  •  SOFTWARE  DOCUMENTATION  -  provides  a  more  thorough  discussion 
of  the  data  bases,  programs,  and  support  files  used  to  build  the  COB. 

3.2.1  What  is  a  CDB  Needline? 

A  COB  needline  i«  a  series  of  related  data  elements  describing  a  requirement 
to  exchange  mission  essential  information  between  two  or  more  battlefield 
communicators.  Two  important  concepts  are  embodied  in  this  simple  definition 
and  merit  further  discussion.  The  first  is  the  words  ...  mission  essential . 

All  needlines  in  the  CDB  are,  by  definition,  mission  essential.  No  needlines 
were  developed  by  TBE  analysts  unless  the  analyst  believed  they  fit  this  criteria. 
Obviously,  this  is  one  of  the  many  areas  in  which  subjectivity  exists.  This  is  also  one 
of  the  principal  reasons  the  COMSR  Data  Base,  previously  discussed,  drifted  into 
obscurity.  The  requirement  for  mission  essentiality  was  at  the  forefront  during 
development,  verification,  and  validation  of  CDB  needlines. 

The  second  important  concept  Is ....  a  series  of  related  data  elements .  A 

CDB  needline  is  composed  of  33  data  elements,  all  of  which  relate  to  a  single 
needline  requirement.  Each  needline  identifies  and  describes  the  purpose  of  the 
communication,  the  originator  of  the  call,  the  receiver,  the  message,  the  number  of 
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times  per  day  the  message  is  sent,  the  type  of  equipment  and/or  data  device  used, 
and  a  number  of  other  descriptors  of  the  requirement.  Needline  data  structure  was 
specified  by  the  government  and  only  minor  changes  to  the  original  structure  have 
been  made  as  the  project  progressed  (See  Figure  3  2.1-1). 


NEEOUWt  DATAELEMEWTS 


ORIGINATOR  SRC 
ORIGINATOm  paragraph 
ORiGIKlATCR  LINE 
NEEDLINE  STATUS 
ORIGINATOR  MUI TIPLIER 
ORIGINATOR  MOBILITY 
RECEIVER  SRC 
RECEIVER  paragraph 
RECEIVER  LINE 
NEEOLINE  status  DATE 
RECEIVER  MULTIPLIER 


RECEIVER  MOBILITY 
UNIT  relationship  CODE 
SUBSET  RATIO 
PURPOSE 
FUNCTION 
MESSAGE  CODE 
length  (MESSAGE) 
MESSAGE  CLASSIFICATION 
FREQUENCY  (MESSAGE) 
COST  OF  FAILURE 
PERISHABILITY 


BROADCAST  CROUP 
MODE 

PRMAR''  I  ./WENT 

secondary  EQuMMENT 
ORIGINATOR  DATA  DEVICE 
REaiVER  data  device 
activity 

interoperability 

intensity 

needline  sequence 


FIGURE  3.2. M  CDS  Needline  Data  Elements 


There  are  two  types  of  needlines.  INTER-unit  needlines  describe 
communications  requirements  between  units  (different  SRCs).  INTRA-unit 
needlines  describe  communications  requirements  within  a  unit  (SRC).  A  company 
commander  talking  to  his  battalion  commander  is  captured  on  an  INTER-unit 
neecilirie  since  Lhey  belong  to  different  SRCs.  A  company  commander  talking  to  his 
platoon  leader(s)  is  captured  on  an  INTRA-unit  needline  since  they  are  assigned  to 
the  same  SRC  (See  Figure  3.2.1  -2). 


f 
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INTER 


FIGURE  3.2. 1-2.  Inter-unit  and  Intra-unit  Needlines 

3.2.2.  How  Were  CDB  Needlines  Built? 

Fundamental  to  an  understanding  of  how  needlines  were  constructed  is  an 
awareness  of  two  key  needline  elements;  PURPOSE  and  FUNCTION. 

People  communicate  for  reasons.  The  mere  possession  of  a  means  by 
communicator  A,  to  talk  to  communicator  B,  does  not  necessarily  establish  a  mission 
essential  requirement  for  him  to  do  so.  Capability  does  not  drive  requirement. 
Hopefully,  the  reverse  would  be  true. 
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The  government  specified  to  TBE  five  reasons  or  "Purposes"  for  which 
communications  requirements  can  exist.  These  were  Command,  Administration, 
Operations,  Intelligence,  and  Logistics.  Each  needline  is  tied  to  one  of  these  five 
Purposes. 

TBE  expanded  this  concept  by  establishing  sub-purposes  or  "Functions" 
which  add  further  specificity  to  the  identification  of  the  reason  for  the  existence  of 
the  communications  requirement.  TBE  analyzed  the  five  specified  Purposes  and 
attempted  to  b'^eak  each  down  into  its  component  Functions.  Through  this  process 
TBE  identified  58  Functions,  each  associated  with  a  Purpose.  Personnel 
Replacements  became  a  Function  associated  with  the  Purpose  of  Administration, 
Repair  Parts  Resupply  became  a  Function  associated  with  the  Purpose  of  Logistics, 
and  so  forth.  Each  needline  carries  both  a  PURPOSE  and  a  FUNCTION  designation 
which,  together,  identify  the  specific  reason  for  the  existence  of  the  needline 
requirement.  Figure  3. 2. 2-1  illustrates  PURPOSES,  FUNCTIONS,  and  their 
relationships. 

3.2.3  Unit  to  Unit  Connections 

Having  identified  the  units  comprising  the  Troop  List  and  the  reasons 
(Purposes/Functions)  these  units  might  communicate  with  one  another,  TBE 
continued  needline  development  by  connecting  units  for  the  various 
Purpose/Function  combinations.  To  do  this,  each  unit  (SRC)  was  placed  in  the 
"object”  position,  and  connected  to  another  unit(s)  for  each  applicable 
Purpose/Function  (See  Figure  3.2. 3-1). 

Not  every  unit  was  connected  to  another  unit  for  each  Purpose/function.  In 
some  cases  a  unit  was  connected  to  more  than  qne  other  unit  for  a  particular 
Purpose/Funrtion.  TBE  Analysts  used  their  personal  experience,  doctrinal  material, 
and  proponent  coordination  to  make  these  unit  to  unit  connections.  These  initial 
conneaions  were  critical  because  they  would  form  the  basis  of  the  needline,  with 
remaining  needline  elements  adding  detail  and  specificity  to  the  connection. 
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FIGURE  3  2.2-1.  CDS  Purposes  and  Functions 
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FIGURE  3. 2. 3-1.  Unit  to  Unit  Connections 


Initial  unit  to  unit  connections  were  always  made  from  the  perspective  of  the 
"object"  unit  to  a  higher  unit  in  its  command  structure  and/or  to  its  supporting 
units.  A  subsequent  needline  development  step  would  reverse  these  initial  lower  to 
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higher,  supported  to  supporting  needlines,  thereby  providing  for  two  way 
connections  where  applicable. 

UNIT  RELATIONSHIP  CODES  (URC)  were  added  to  neediines  at  this  time.  URC 
specify  the  relationship  between  the  connected  units  (chain  of  command,  direct 
Support,  area  support,  etc.).  URC  are  intended  for  use  in  conjunction  with  modeling 
applications,  such  as  the  NAM,  during  the  OPFAC  laydown  and  connection  stages  of 
scenario  input. 

A  more  thorough  explanation  of  Unit  Relationship  Codes  and  other  needline 
elements  can  be  found  at  Appendix  B  -  CDB  NEEDLINE  CODEBOQK  AND  USER'S 
MANUAL  FOR  PROPONENT  VERIFICATION. 

3.2.4  Person  to  Person  Connections 

The  next  step  in  the  needline  development  process  involved  the 
identification  of  the  specific  communicators  originating  and  receiving  tne 
communication. 

The  SIGC.EN  provided  SRC  Documentation,  including  a  listing  of  Personnel 
and  Equipment  authorized  to  each  unit  on  the  CDB  Troop  List.  No  such  data  was 
available,  of  course,  for  notional  (SRC  99  series)  organizations.  TBE  was  tasked  to 
identify,  on  each  needline,  the  specific  communicators  (originator  and  receivei)  of 
the  information  being  exchanged  Each  needline  war  to  detail  the  specific  SRC, 
Paragraph  Number,  and  l  ine  Number  for  both  the  originator  and  the  receiver. 

TBE  analyzed  SRC  documents  to  identify  communicators.  As  a  general  rule, 
personnel  in  grade  E'4  and  below  were  eliminate  I  from  consideration  as 
communicators.  This  general  rule  was  applied  to  limit  the  population  of  potential 
communicators  and  because  our  analysts  believ-jJ  ihat  mcst  communications  were 
originated  and  received  by  personnel  in  grade  £-5  and  above.  Of  course  this  general 
rule  is  not  universally  true,  and  analysts  made  adjustments  by  adding,  or  deleting, 
specific  communicators  during  their  SRC  by  SRC  review  of  the  entire  7 1  nop  List. 
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A  significant  problem  to  be  overcome  was  a  lack  of  standardization  of 
Position  Titles  within  the  T.O.&E.  System.  As  documents  were  reviewed  our  analysts 
observed  many  different  titles  assigned  to  the  same  functional  positions.  For 
example,  different  SRCs  contained  titles  Company  Commander,  Co.  Cdr.,  Company 
CDR,  Commander,  CDR.  DET  CDR,  etc.,  nineteen  different  variations,  for  the  same 
functional  position.  TBE  developed  a  standard  list  of  Position  Titles  and  conducted  a 
line  by  line  review  of  each  SRC  document.  Analysts  assigned  a  standard  Position 
Title  and  COMMUNICATOR  CODE  to  each  communicator  in  each  SRC  document. 
Through  this  process  our  analysts  reduced  the  number  of  Position  Titles  from  over 
22,000  to  less  than  2,000.  This  standardization  of  Position  Titles  and  the  assignment 
of  COMMUNICATOR  CODES  allowed  us  to  proceed  with  needline  development, 
next  connecting  a  speci'ic  originator  communicator  to  a  specific  receiver 
co.mmunicator  for  each  existing  unit  to  unit  needline. 

TBE  Analysts  developed  hierarc.^ically  ordered  sets  of  Communicator  Codes 
for  each  Purpose/Function.  These  sets  were  ordered  such  that  the  Communicator 
Code  at  the  top  of  the  list  would  be  the  person  who  would,  if  found  in  a  unit,  be  the 
most  'ikely  individual  to  handle  a  particular  Purpose/Function.  The  Communicator 
Code  at  the  bottom  of  the  list  would  be  the  person  who  would,  if  he  were  the  only 
one  on  the  list  found  in  a  unit,  be  most  likely  to  handle  the  communications  for  the 
particular  Purpose/Function.  Separate  sets  were  developed  for  originators  and 
receivers.  For  example,  the  set  of  Communicator  Codes  developed  for  originators 
for  the  Purpose/Function  "Administration/Personnel  Replacements"  are  shown  at 
Figure  3. 2. 4-1. 
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ADMIN  •  PERSONNEL  REPLACEMENTS 
MASTER  ORIGINATOR  EXTRACT  LIST 


RANK 


COMMUNICATOR 


1 

2 

3 

4 

5 


PERS  STF  NCO 
PAC  SUPVR 
PERS  RECORDS  SPEC 
PERSMGT  SPEC 
PERS  ACT  SPEC 


65  other  communicators 


71 

72 

73 

74 


MAILDISTR  SPEC 
PROCUNITSUPVR 
SECRETARY 
FIRST  SGT 


FIGURE  3.2.4-1.  Communicator  Codes 


Using  these  ordered  sets  of  communicators  and  the  unit  to  unit  needlines, 
previously  developed,  TBE  Software  Engineers  developed  programs  which  searched 
communicating  units  for  the  highest  listed  communicators  for  each 
Purpose/Function  combination.  Only  one  communicator  (originator  or  receiver)  was 
selected  from  each  SRC  for  any  individual  Purpose/Function.  Figure  3. 2. 4-2 
illustrates  this  process. 

At  the  completion  of  this  step,  ncedlines  specified  the  SRC,  Paragraph,  and 
Line  for  both  the  originator  and  receiver,  as  well  as  the  Purpose  and  Function,  for 
each  needline  requirement  in  the  data  base. 
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FIGURE  3  2  4-2.  Person  to  Person  Connections 
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3.2.5  Message  Assignments 

The  government  provided  TBE  with  a  list  of  messages  to  be  used  for  building 
needlines.  This  list  identified  432  messages,  primarily  United  States  Message  Text 
Formats  (USMTF),  which  were  listed  by  MESSAGE  CODE  (a  six  digit  identification 
code  number),  Message  Name,  Minimum  Length,  and  Maximum  Length.  This 
message  list  is  oriented  primarily  on  voice  and  record  (non-data)  messages.  TBE 
used  this  list  as  the  single  source  for  message  assignments,  by  direction  of  the 
government. 

In  a  manner  similar  to  that  described  above  (Person  to  Person  Connections) 
TBE  established  sets  of  messages  relating  to  each  Purpose/Function  combination. 
Purppse/Function  message  sets  were  developed  in  both  Forward  (lower  to  higher, 
supported  to  supporting)  and  Reverse  (higher  to  lower,  supporting  to  supported) 
groups.  Recall  that  up  to  this  point  we  had  been  dealing  with  needlines  developed 
in  the  Forward  direction.  Software  Engineers  developed  programs  which  would  not 
only  assign  messages  to  each  existing  Forward  needline,  but  would  also  create 
Reverse  needlines,  concurrently  assigning  messages  to  those  newly  created  Reverse 
needlines.  FIGURE  3. 2. 5-1  illustrates  this  process. 

At  this  point  TBE  also  assigned  MESSAGE  LENGTHS  to  each  needline.  This  was 
accomplished  by  using  the  Minimum  Lengths  and  Maximum  Lengths  obtained  from 
the  government  provided  Message  List  described  above.  TBE  Analysts  developed 
algorithms  allowing  Software  Engineers  to  write  software  which  assigned  MESSAGE 
LENGTHS  to  needlines  based  upon  the  echelons  (company,  battalion,  brigade,  etc.) 
of  the  connected  SRCs. 

3.2.6  Mode  and  Equipment  Assignments 

MODE  of  Transmission  was  assigned  based  upon  an  Analyst’s  assessment  of 
what  the  "preferred"  MODE  would  be,  from  the  perspective  of  the  originator. 
Factors  considered  in  making  this  determination  included  the  message  being  sent. 
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FIGURE  3  2.5-1.  Message  Assignments 


its  length,  the  echelons  of  the  communicating  units,  their  proximity  to  the  Forwarci 
Line  of  T roops  (FLOT),  and  any  other  factors  available  to  aid  this  assignment  process. 

PRIMARY  EQUIPMENT,  SECONDARY  EQUIPMENT,  and  DATA  DEVICE  were  the 
next  needline  elements  to  be  assigned.  Figure  3. 2.6*1  illustrates  this  process.  Values 
assigned  to  these  elements  were  primarily  determined  by  the  availability  of 
communications  and  automation  devices  authorized  to  the  communicators  in  the 
Equipment  Section  of  their  SRC  Documents.  Software  was  developed  to  search 
authorization  documents,  paragraph  by  paragraph,  to  find  communications  and 
automation  equipment  compatible  between  connected  communicators  and 
compatible  with  MODE  assignments  previously  developed.  In  cases  where  no 
communications  or  automation  equipment  was  available  for  assignment,  needlines 
were  assigned  values  representing  "desired"  equipment  choices.  This  methodology 
was  adopted  for  the  following  reasons; 

1)  It  allows  for  the  easy  identification  of  communications 
requirements  not  supported  in  SRC  Documentation  witi 
appropriate  communications/automation  capability. 

2)  It  allows  for  an  easy  transition  from  an  "SRC"  oriented  equipment 
search  to  an  "OPFAC"  oriented  search  as  soon  as  the  OPPAC  Data 
Base  can  be  made  available  to  support  such  analysis. 

3)  It  provides  a  degree  of  discipline  to  the  data  base.  An 
unconstrained  assignment  process  would  have  allowed 
equipment  assignments  to  be  made  without  regard  for  actual 
availability.  This  process  was  employed  to  provide  a  rational  basis 
for  equipment  assignment  while  still  allowing  for  maximum 
analytical  utility  and  flexibility. 

Appendix  6  lists  EQUIPMENT  and  DATA  DEVICE  codes  found  in  the  CDB. 

3.2.7  Other  CDB  Needline  Elements 

The  remaining  CDB  needline  elements  were  developed  using  a  step  by  step 
approach  similar  to  that  already  described.  As  each  step  was  completed,  needlines 
were  expanded,  element  by  element,  until  all  elements  had  been  completed  (Figure 
3. 2. 7-1).  Throughout  the  developmental  process.  Systems  Analysts  and  Software 
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FIGURE  3  2.6*1.  Equipment  Assignment  Process 
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Engineers  tofUinued  to  review  needline  elements,  both  individually  and  collectively, 
making  changes  to  methodology  and/or  software  as  necessary.  The  Contracting 
Officer’s  Technical  Representative  (COTR)  was  continually  involved  in  this  process. 
The  task  was  to  develop  a  data  base  of  needlines,  in  the  structure  specified  by  the 
government,  which  would  be  presented  to  proponents  and  CACOA  for  their 
respective  verification  and  validation. 


3.3  VERIFICATION  AND  VALIOATION 

The  CDB  has  been  verified  by  proponents  and  validated  by  the  Combined 
Arms  Center  (CAC)  for  TRADOC.  Verification  and  validation  of  division  and  corps 
data  was  conducted  May-November,  1987.  Verification  and  validation  of  EAC  data 
occurred  November,  1988  through  March,  1989.  Because  these  two 
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verification/validation  processes  were  conducted  in  a  significantly  different  manner. 

they  will  be  discussed  separately. 

3.3.1  Division  and  Corps  Data 

TBE  completed  development  of  Division  and  Corps  needline  data  in  April, 
1987.  Concurrently,  TBE  had  developed  a  comprehensive  proponent  verification 
process,  along  with  software,  to  be  used  by  proponents  to  accomplish  their 
verification  actions.  The  needline  data  and  the  verification  process,  with  its 
supporting  software  package,  were  briefed  to  and  approved  by  the  government 
during  April*  May,  1987. 

In  May,  1987  a  combined  SIGCEN/TBE  team  visited  the  five  BFA  Centers, 
briefing  the  CDB  to  assembled  Proponent  Project  Officers,  demonstrating  the 
verification  software,  and  providing  them  with  software  and  their  needline  data. 
Proponents  were  instructed,  by  the  SIGCEN,  to  complete  their  verification  and 
return  their  corrected  data  diskettes  to  the  SIGCEN  within  thirty  days. 

In  June,  1987  a  meeting  of  all  proponents,  at  the  SIGCEN,  was  directed  by 
CACDA.  At  this  meeting,  CACOA  re-directed  the  verification  effort.  CACDA  decided 
proponents  would  conduct  a  separate  verification  of  divisional  <>nd  corps  data. 
Divisional  needlines  would  be  verified  first,  immediately  followed  by  a  verification 
of  corps  data.  Additionally,  CACDA  directed  that  proponents  would  not  use  the 
verification  software  developed  by  TBE,  but  would  instead  record  all  needline 
changes  on  paper,  handwritten,  and  forward  these  changes  to  the  SIGCEN  for  input 
to  the  data  base.  At  this  meeting,  and  at  a  subsequent  meet,  ig  (18  June,  1987,  in 
Atlanta),  CACDA  directed  other  changes  to  the  verification  process.  CACDA's  stated 
purpose  in  directing  these  changes  was  to  ease  the  burden  on  proponents,  to 
improve  the  quality  of  the  data  base,  and  to  provide  the  data  base  (first  the  division, 
then  corps)  to  OTEA  in  preparation  for  its  Follow-on  Test  and  Evaluation  (FOT&E)  of 
the  Mobile  Subscriber  Equipment  (MSE). 
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In  addition  to  splitting  the  data  base  for  verification,  CACDA  directed  several 
other  changes.  Among  those  changes  directed,  was  to  remove  all  but  "normal” 
MOBILITY  and  ACTIVITY  needlines,  to  restrict  or  remove  the  ability  of  some  specific 
COMMUNICATOR  COOES  to  communicate,  to  decrease  the  number  of  Command 
PURPOSE  needlines,  and  to  eliminate  most  divisional  TACFIRE  needlines.  CACDA 
also  provided  a  different  list  of  MESSAGES  for  application  to  needlines  and  directed 
the  SIGCEN  to  develop  a  conversion  process  to  convert  "old"  messages  to  "new" 
messages  in  accordance  with  the  new  list  of  messages.  Finally,  CACOA  directed  a 
different  needline  print-out  format  for  needline  presentation  to  proponents.  This 
new  format  reduced  the  number  of  needline  elements  proponents  would  see  for 
verification,  thereby  easing  their  verification  tasks.  All  CACDA  directed  changes 
were  implemented  by  the  SIGCEN.  The  Division  and  Corps  Data  Bases  were  verified 
by  proponents  June-October,  1987  and  validated  by  CACDA  and  the  Combined 
Arms  Center  (CAC)  in  November,  1987.  Needline  data  from  the  CDB  was  provided  to 
and  used  by  OTEA  for  MSE  FOT&E  at  Fort  Hood,  Texas.  Figure  3. 3. 1-1  depicts  this 
process. 

3.3.2  Echelons  Above  Corps  Needtines 

TBE  completed  development  of  EAC  needline  data  in  October,  1988. 
Concurrent  with  needline  development,  TBE  also  designed  a  Proponent  Verification 
Process  and  designed  and  developed  a  comprehensive,  user  friendly  software 
system  for  proponent  use  during  their  verification  of  needline  data.  On  2 
November,  1988  a  briefing/software  demonstration  was  conducted  at  Fort  Gordon 
by  a  combined  SIGCEN/TBE  Team.  All  BFA  Proponents,  most  Branch  Proponents, 
and  CACOA  were  represented  at  this  meeting.  Following  a  detailed  briefing  on  the 
COB,  its  purpose,  history  and  developmental  methodology,  proponents  were 
provided  a  comprehensive  demonstration  of  CDB  Verification  Software.  Proponents 
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VERIFICATION  /  VALIDATION 
DIVISION  AND  CORPS  NEEDLINES 


FIGURE  33.1-1.  Division  and  Corps  Needline  VerificationA/alidation 
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were  provided  copies  of  their  needline  data,  all  required  support  files,  and 
software  routirtes  necessary  for  them  to  conduct  their  verification  actions.  The 
SIGCEN  requested  proponents  complete  their  verification  actions  and  return 
needline  data  diskettes  to  the  SIGCEN  in  preparation  for  CACOA/CAC  Validation, 
figure  3. 3. 2-1  depicts  this  process. 

VERIFICATION  /  VALIDATION 
EAC  NEEDLINES 


FIGURE  3. 3. 2-1.  EAC  Needline  VerificationA/alidation 
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4.  SUMMARY  AND  RECOMMENDATIONS 


4.-!  SUMMARY 

The  Signal  Center  exercises  proponent  responsibility  for  battlefield 
communications  and  automation  as  well  as  the  other  Theater/Tactical  Information 
Mission  Area  sub-disciplines.  At  the  heart  of  these  responsibilities  is  a  necessity  to 
conduct  continuing  requirements  vs.  capabilities  analysis  of  systems,  both  current 
and  proposed,  supporting  the  function  of  battlefield  information  exchange. 

Analysis  must  be  credible  and  feasible.  Results  achieved  through  analysis  will 
not  only  be  used  by  the  Signal  Center  fo'  architecture  design  and  doctrine 
development,  but  will  also  be  used  by  higher  level  Army  and  Defense  decision 
makers  in  deciding  which  programs  and  acquisitions  will  be  supported,  and  which 
will  not.  History  has  proven  that  one-time,  special  purpose,  manpower  intensive 
but  analytically  feeble  attempts  to  answer  requirements  vs.  capabilities  questions 
cannot  endure.  The  Signal  Center  sorely  needs  a  credible,  sanctioned  analytical 
capability  to  support  its  Combat  Developments  activities. 

The  CDB  is  one  leg  of  the  Signal  Center's  Analytical  Triad.  The  CDB,  in 
conjunction  with  the  OPFAC  Data  Base  and  the  Network  Assessment  Model,  will 
provide  the  Signal  Center  with  the  analytical  tools  needed  to  perform  its  analysis  of 
battlefield  communications  and  automation  requirements  vs.  capabilities. 

The  CDB  has  been  developed  by  the  Signal  Center  using  a  logical  and 
consistent  developmental  methodology.  The  data  base  has  been  designed  and  built 
to  overcome  the  difficulties  encountered  by  previous  attempts  to  quantify 
battlefield  communications  requirements.  The  CDB  has  been  verified  by  all 
TRADOC  Proponents  and  has  been  validated  by  the  Combined  Arms  Center.  In 
achieving  this  TRADOC  certification,  it  becomes  the  single,  sanctioned  repository  of 
battlefield  communications  requirements  data  for  the  entire  Army. 
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4.2  RECOMMENDATIONS 


The  following  actions  are  recommended  to  insure  the  Signal  Center  receives 
maximum  utility  from  the  Communications  Data  Base: 

^)  The  SIGCEN  institutionalize  a  periodic  (annual)  process  by  which 
the  data  base  can  be  re-verified  and  re-validated.  Such  a  process 
is  required  to  maintain  the  currency  of  the  data  and  to  allow  it  to 
keep  pace  with  changes  in  doctrine,  and  organizations.  This 
process  should  be  institutionalized  by  TRADOC  or  Army 
Regulation  (AR  105-9  institutionalized  the  COMSR  Data  Base).  If 
this  is  not  done,  the  data  base  will  soon  lose  its  credibility  and 
Support  throughout  the  Army. 

2)  The  COB  be  expanded  to  include  those  Battlefield  Automated 
Systems  cither  currently  not  included,  or  only  partially  included, 
in  the  data  base.  As  was  pointed  out  in  the  text,  the  CDB  has 
been  developed  to  quanti^  requirements  associated  with  those 
equipments  currently  appearing  in  SRC  documentation.  It  has 
always  been  the  SIGCEN's  intention  to  expand  the  data  base  by 
developing  requirements  data  for  developmental 
communications  and  automation  systems  so  that  their  impacts  on 
the  network(s)  could  be  analyzed.  Because  of  the  magnitude  of 
this  issue,  and  the  requirement  for  timely  decisions,  this 
expansion  should  be  accomplished  as  a  matter  of  priority. 

3)  The  CDB  be  expanded  to  include  additional  SRCs  required  to 
allow  a  broader  range  of  architectural  analysis.  The  current  data 
base  includes  767  SRCs.  as  has  been  pointed  out.  A  prioritized  list 
of  SRCs  should  be  developed  and  needline  data  should  be 
developed  for  these  SRCs  in  accordance  with  the  established 
prioritization  and  funds  availability. 

4)  The  Analytical  Triad  (the  CDB,  the  NAM,  and  the  OPFAC  Data 
Base)  be  viewed  and  managed  as  a  cohesive,  inseparable  set  of 
analytical  tools.  Because  these  three  elements  are  so  interrelated 
and  interdependent,  they  cannot  be  viewed  and  managed  as 
separate  entities.  They  must  be  developed  and  maintained  as  a 
package.  Changes  to  one  or  another  must  be  made  only  with 
cognizance  of  the  effects  of  these  changes  on  the  other  two  legs 
of  the  triad.  All  three  legs  must  be  coordinated  and  harmonized 
to  support  the  total  analytical  capability. 

TBE  has  worked  with  the  Signal  Center  to  build  the  CDB,  the  NAM  and  to 
harmonize  the  OPFAC  Data  Base.  TBE  understands  the  issues  associated  with  the 
CDB  as  well  as  the  two  other  legs  of  the  triad.  TBE  will  work  with  the  Signal  Center 
to  implement  these  recommendations  or  provide  any  other  support  necessary  to 
support  the  analytical  'efforts. 
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APPENDIX  A.  COB  SOFTWARE  DOCUMENTATION. 


APPENDIX  A.  COB  SOFTWARE  DOCUMENTATION 


This  appendix  will  detail  the  structures  and  relationships  of  the  primary  and 
direct  support  databases  comprising  the  COB.  The  COB  system  utilizes  the  dBASE  III 
Plus  database  management  system  on  an  IBM  compatible  Personal  Computer. 
Figure  A-l  lists  these  databases  and  their  alias  name.  Many  other  databases  were 
used  to  build  the  primary  databases,  support  the  verification  effort,  and  produce 
reports  throughout  the  development  of  the  COB  system.  Only  the  primary  and 
direa  support  databases  are  documented  in  this  appendix. 


DATABASE 

ALIAS 

CRDB01 

WORK  NDLN 

CRDB03 

SRC  MASTER 

CRDB04 

TOr"  PEOPLE 

CRDB08 

COMMCODES 

CRDB09 

SEaiONS 

CRDB12 

PF  CODE 

CRDB13 

MSG  CODE 

CRDB14 

ZONE"  CODE 

CRDB16 

NCLAS"  CODE 

CRDB17 

MODE“CODE 

CRDB13 

URC  CODE 

CROB19 

MOB"  CODE 

CRDB20 

NTROF  CODE 

CRDB21 

ACT  CODE 

CRDB22 

SOS  “CODE 

CRDB23 

COr"CODE 

CRDB24 

ECh“CODE 

CRDB25 

PROP"  CODE 

CRDB26 

INTEN"  CODE 

CRDB27 

EOUIP“CODE 

CRDB28 

TCIAS“COOE 

CRDB30 

DD  CODE 

CRDB40 

CDBT  LIN 

CRDB41 

EQUIP  SPL 

CRD842 

E0UIP“SP 

BRIEF  DESCRIPTION 


Primary  needline  definition. 

Description  of  each  SRC  in  CDB. 

Description  of  communicators  in  every  SRC. 
Communicator  codes  &  names. 

Paragraph  titles. 

Purpose/function  codes  &  names. 

Message  codes  &  definitions. 

Zone  codes  &  defi.titions. 

Needline  classification  codes  &  names. 
Mode  codes  &  names. 

Unit  relationship  codes  &  names. 

'bility  codes  &  names. 

^roperability  codes  &  names. 

7'ty  codes  &  names, 
f .  I  ish  3bility  codes  &  names. 

Cost  of  failure  codes  &  names. 

Echelon  codes  &  names. 

Proponent  codes  &  names. 

Intensity  codes  &  names. 

Equipment  codes  &  names. 

Traffic  classification  codes  &  names. 

Data  device  codes  &  names. 

Line  Item  Numbers  &  nomenclatures. 
5RCPARA/UN  assignments. 

SRC  equipment  summary  database. 


FIGURE  A'1.  Database  &  Alias  Names  with  Brief  Description. 
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I.  DATABASE  DICTIONARY 

This  section  will  detail  the  primary  i  elds  within  each  of  the  databases  in  the 
CDB  system.  The  field  name,  type,  width,  and  description  is  listed.  The  field  types 
are; 


CHARACTER:  These  fields  can  store  any  printable  character  that  can 
be  entered  from  the  keyboard. 

MEMO:  This  type  of  field  allows  for  storage  of  large  amounts  of 
textual  data.  Each  memo  field  uses  only  10  characters  per  record  in 
the  database. 

NUMERIC:  There  are  two  types  of  numeric  fields.  Integer  fields 
contain  a  whole  number  with  no  decimal  places  while  decimal  fields 
contain  a  specific  number  of  decimal  places.  The  first  number  of  the 
width  definition  describes  the  maximum  number  of  digits.  The 
minus  sign  and  decimal  point  each  count  as  one  digit.  The  following 
examples  show  the  minimum  and  maximum  values  for  associated 
width  definitions 


WIDTH 

MIN 

MAX 

6 

-99999 

9l'C999 

6.1 

-999.9 

9999.9 

3.1 

-.9 

9.9 

-2 


DATABASE:  CROB01 


DESCRIPTION:  This  database  describes  the  requirement  for  communicators  to 
exchange  "mission  essential"  information.  Each  record  in  this  database  represents 
one  "needline".  The  needlines  are  described  in  great  detail. 


Ndin _ class 

Ndin _ seq 

Broad _ grp 

Org__src 

Org _ para 

Org_line 

Rcvr _ src 

Rcwr _ para 

Rcvr _ line 

Urc 

Subset  rat 


TYPE:  Character  WIDTH:  1 

The  classification  of  the  needline. 

TYPE:  Numeric  WIDTH:  6 

This  data  element  provides  a  unique  reference  number  for 
each  needline. 

TYPE:  Numeric  WIDTH:  4 

This  data  element  describes  a  group  of  needlines  which  are 
sent  by  a  single  originator,  simultaneously,  to  a  group  of 
receivers  usino  communications  means  whicn  lend  themselves 
to  multiple  addressee  transmissions. 

TYPE:  Character  WIDTH:  9 

The  standard  requirements  code  of  the  unit  originating  a  call 
to  another  unit. 

TYPE:  Character  WIDTH:  2 

The  paragraph  number  within  the  SRC  where  the  originating 

communicator  is  located. 

TYPE:  Character  WIDTH:  2 

The  line  number  within  the  paragraph  of  the  SRC  that 
specifies  the  communicator  originating  the  call. 

TYPE:  Character  WIDTH:  9 

The  standard  requirements  code  of  the  unit  receiving  a  call 
from  another  unit. 

TYPE:  Character  WIDTH:  2 

The  paragraph  number  within  the  SRC  where  the  receiving 
communicator  is  located. 

TYPE:  Character  WIDTH;  2 

The  line  number  within  the  paragraph  of  the  SRC  that 
specifies  the  communicator  receiving  the  call. 

TYPE  Character  WIDTH:  2 

This  element  describes  the  relationship  between  the  SRC  of 
the  originator  and  the  SRC  of  the  receiver. 

TYPE  Character  WIDTH:  4 

This  data  element  describes  the  number  of  originators  and  the 
number  of  receivers  represented  on  the  needline.  That  is.  how 
many  originators  are  talking  to  how  many  receivers? 
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DATABASE:  CRDB01  (continued) 


Purpose 

Function 

Msg _ code 

Activity 

Org _ mobil 

Rcvr _ mobil 

Mode 

Prime _ eq 

Sec _ eq 

Org _ d__dev 

Rcvr  d  dev 


TYPE:  Character  WIDTH;  1 

This  data  element  describes  the  purpose  for  which  this 
needline  exists. 

TYPE;  Chararter  WIDTH:  2 

This  element  describes  the  function  within  each  of  the 
purposes  for  which  a  needline  exists. 

TYPE;  Character  WIDTH:  6 

This  field  describes  the  message  being  sent  between  the 
originator  and  receiver. 

TYPE;  Character  WIDTH:  1 

This  element  specifies  that  the  needline  applies  only  when  a 
certain,  specified  activity  is  being  accomplished  by  the 
communicator(s). 

TYPE:  Character  WIDTH:  1 

This  element  specifies  that  the  needline  applies  only  when  the 
originator  meets  this  mobility  condition. 

TYPE:  Character  WIDTH;  1 

This  element  specifies  that  the  needline  applies  only  when  the 
receiver  meets  this  mobility  condition . 

TYPE;  Character  WIDTH:  1 

This  data  element  describes  the  desired  mode  by  which  the 
needline  should  be  satisfied.  Modes  are  assigned  without 
considering  equipment  available  to  the  communicators. 

TYPE:  Character  WIDTH;  2 

This  element  describes  the  primary  equipment  that  will  be 
used  to  satisfy  the  needline  requirement.  Both 
communicators  must  possess  the  equipment  specified  by  this 
element. 

TYPE;  Charaaer  WIDTH:  2 

When  the  primary  equipment  is  not  available  to  both 
communicators,  then  the  secondary  equipment  will  be  used  to 
satisfy  the  needline  requirement. 

TYPE:  Character  WIDTH:  3 

This  data  element  describes  the  data  terminal  device  being 
used  by  the  originator.  This  applies  to  needlines  with  a  mode 
of  “data" 

TYPE;  Character  WIDTH:  3 

This  data  element  describes  the  data  terminal  device  being 
used  by  the  receiver.  This  applies  to  needlines  with  a  mode  of 
“data*^. 
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DATABASE;  CROB01  (continued) 


Freq _ xmit 


Msg _ length 


Perish 


Cof 


Intensity 


Msg_class 


Interop 


TYPE:  Numeric  WIDTH:  6.1 

This  data  element  describes  the  number  of  times,  per  24-hour 
period,  the  message  identified  on  the  needline  is  set  between 
the  originator  and  receiver. 

TYPE;  Numeric  WIDTH:  6.0 

This  element  defines  the  length  of  the  message  being  sent 
between  the  originator  and  receiver.  The  unit  of  measure  is 
always  'characters”. 

TYPE:  Character  WIDTH;  1 

This  data  element  describes  the  amount  of  time,  from  the 
perspeaive  of  the  originator,  that  can  be  allowed  to  elapse 
from  the  time  he  sends  his  message  until  the  intended 
receiver(s)  receives  it. 

TYPE;  Character  WIDTH:  1 

This  data  element  describes  the  effect,  on  the  ability  of  the 
originator,  to  accomplish  his  mission,  if  this  needline  is  not 
satisfied. 

TYPE:  Character  WIDTH:  1 

This  element  describes  the  effect  of  changes  in  the  levels  of 
intensity,  with  which  the  originating  unit  is  involved  in 
performing  its  mission,  on  the  volume  of  message  traffic 
represented  on  the  needline. 

TYPE;  Character  WIDTH:  1 

This  element  represents  the  highest  level  of  classification 
expected  for  the  traffic  carried  on  the  needline.  It  refers  to 
the  text  of  the  message. 

TYPE;  Character  WIDTH:  1 

This  data  element  indicates  a  requirement,  or  lack  thereof,  for 
the  equipment  to  EVER  have  the  need  to  interoperate  with 
non-US  Army  equipment  in  a  NATO  environment. 
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DATABASE:  CRDB03 


DESCRIPTION:  This  database  contains  information  about  the  SRC's  used  in  CDB. 
The  SRC's  name,  it's  proponent  identification,  and  a  set  of  codes  used  to  associate 
the  SRC  with  a  CDB  Phase  are  the  most  often  used  data  elements. 


Src 

Name 

Proponent 

Bfa 

Echelon 


TYPE:  Character  WIDTH:  9 

This  data  element  identifies  the  standard  requirements  code 
of  a  group  of  units.  The  information  associated  with  e  j  'h  SRC 
was  extracted  from  the  TOE  master  files  at  Ft.  Leavenworth. 

TYPE;  Character  WIDTH:  26 

This  element  is  the  name  of  the  SRC. 

TYPE:  Character  WIDTH:  1 

This  field  represents  the  proponent  code  of  the  SRC. 

TYPE;  Character  WIDTH:  1 

This  field  represents  the  battlefield  functional  area  of  the  SRC. 

TYPE:  Chararter  WIDTH;  1 

This  element  describes  the  echelon  of  the  SRC. 


DATABASE;  CRDB04 


DESCRIPTION:  This  database  contains  information  describing  the  communicators  in 
each  SRC.  Each  communicator  is  uniquely  identified  by  its  SRC.  paragraph,  and  line. 


Src 

Para 

Line 

Position 

Multiplier 

Mos 

Grade 

Comm__cod€ 
Fake _ para 


Fake  line 


TYPE;  Character  WIDTH;  9 

The  standard  requirements  code  of  the  unit. 

TYPE:  Character  WIDTH;  2 

The  paragraph  within  the  SRC. 

TYPE:  Character  WIDTH;  2 

The  line  number  within  the  paragraph  of  the  SRC. 

TYPE:  Character  WIDTH:  22 

The  actual  job  title  associated  with  a  particular  SRC, 

paragraph,  and  line  (SPL). 

TYPE;  Numeric  WIDTH:  2 

The  number  of  people  performing  the  same  job  within  this 
paragraph. 

TYPE:  Charaaer  WIDTH:  5 

The  military  occupational  specialty. 

TYPE:  Cliaracter  WIDTH;  2 

The  military  rank  authorized  for  each  SPL. 

TYPE:  Character  WIDTH:  4 

This  field  is  a  communicator  code  assigned  to  each  SPL  in  an 
attempt  to  standardize  the  names 

TYPE:  Character  WIDTH:  2 

This  data  element  reflects  the  paragraph  number  than  an  SPL 
works  out  of.  Some  personnel  are  listed  in  the  "command 
section"  of  the  SRC  while  actually  working  out  of  a  different 
paragraph.  This  fake  paragraph  represents  the  paragraph 
they  really  belong  with. 

TYPE  Charaaer  WIDTH:  2 

This  element  is  used  to  represent  a  unique  line  number  for  a 
person  when  that  persons  paragraph  of  assignment  (Para)  and 
his  work  paragraph  (Fake  para)  are  different.  In  these  cases 
the  Fake  line  is  always 'A,  B',  or 'C'. 
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DATABASE;  CRDB08 


DESCRIPTION:  Thi&  database  contains  a  standardized  list  of  communicator  titles 
and  their  associated  comm  code. 


Title  TYPE:  Character  WIDTH;  29 

This  field  is  a  standardized  name  of  a  communicator. 

Comm code  TYPE;  Character  WIDTH;  4 

A  unique  code  assigned  each  standard  communicator  title. 


DATABASE:  CROB09 


DESCRIPTION:  This  database  contains  the  paragraph  titles  for  each  paragraph  of 


each  SRC. 

Src 

TYPE:  Character  WIDTH:  9 

The  standard  requirements  code. 

Para 

TYPE:  Character  WIDTH:  2 

A  paragraph  within  the  SRC. 

Section 

TYPE;  Character  WIDTH;  21 

The  paragraph  title. 

DATABASE:  CR0B12 


DESCRIPTION:  This  database  defines  each  purpose/funaion  pair  used  throughout 
CDB. 


Pf code  TYPE;  Character  WIDTH;  3 

The  concatenation  of  a  purpose  code  and  a  function  code. 

Descript  TYPE:  Character  WIDTH;  25 

This  data  element  is  the  description  of  a  'Pf  code'. 
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DATABASE;  CRDB13 


DESCRIPTION:  This  database  defines  and  describes  each  message  code  used  in  COB. 


Msg _ code 

Long _ desc 

Msg _ def 

Proponent 

Subject 

Source 

Min _ length 

Max _ length 


TYPE;  Character  WIDTH;  6 

This  data  element  is  the  message  code. 

TYPE:  Character  WIDTH;  50 

This  element  provides  a  50  character  description  of  the 

message. 

TYPE;  Memo  WIDTH;  10 

This  element  provides  for  a  complete  definition  of  the 

message. 

TYPE;  Charaaer  WIDTH;  1 

This  element  specifies  the  proponent  activity  that  defined  a 
need  for  the  message. 

TYPE;  Character  WIDTH;  1 

A  code  used  to  specify  the  general  subject  matter  of  the 
message. 

TYPE;  Character  WIDTH.  1 

A  code  used  to  indicate  the  message  source  Possible  sources 
are  'STANAG',  ‘ACCS',  'USMTF',  'MCS'  or  'FLIRP*. 

TYPE;  Numeric  WIDTH;  6 

This  element  expresses  the  minimum  message  length  in 
characters. 

TYPE;  Numeric  WIDTH:  6 

This  element  expresses  the  maximum  message  length  in 
characters. 


DATABASE:  CRDB14 


DESCRIPTION:  This  database  describes  each  zone  code  used  in  CDB. 


Zone code  TYPE;  Character  WIDTH;  1 

A  unique  code  assigned  each  z,one  of  the  battlefield. 

Descript  TYPE;  Character  WIDTH;  66 

The  description  of  each  battlefield  zone. 
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DATABASE;  CRDB16 


DESCRIPTION:  This  database  describes  each  needline  classification  code  used  in 
CDB. 


Nclas^code  TYPE;  Character  WIDTH;  1 

A  unique  code  assigned  each  classification  level.  This  set  of 
codes  will  describe  the  classification  of  the  needline  itself,  not 
the  traffic  represented  by  the  needline. 

Oescript  TYPE;  Character  WIDTH;  12 

The  description  of  each  needline  classification  code. 


DATABASE:  CROB17 


DESCRIPTION:  This  database  describes  each  mode  code  used  in  CDB. 


Mode_code  TYPE:  Character  WIDTH;  1 

A  unique  code  assigned  to  each  possible  mode  of 
transmission. 

Oescript  TYPE:  Character  WIDTH.  9 

The  description  of  each  mode  of  transmission. 


DATABASE:  CRDB18 

DESCRIPTION:  This  database  describes  each  URC  code  used  in  CDB. 

Urc__code  TYPE:  Character  WIDTH:  2 

An  unit  relationship  codes. 

Descript  TYPE:  Character  WIDTH:  60 

The  description  of  each  unit  relationship  code. 
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DATABASE:  CR0B19 


DESCRIPTION;  This  database  describes  each  mobility  code  used  in  CDB. 


Mob_code  TYPE;  Character  WIDTH:  1 

A  code  representing  a  mobility.  This  mobility  is  used  to  qualify 
a  needline.  When  a  communicator  does  not  match  its 
required  mobility,  then  the  needline  is  not  to  be  used. 

Descript  TYPE;  Character  WIDTH:  27 

The  description  of  each  mobility  code. 


DATABASE:  CROB20 


DESCRIPTION:  This  database  describes  each  interoperability  code  used  in  COB. 


Ntrop code  TYPE:  Cha  icter  WIDTH;  1 

An  interoperability  code. 

Descript  TYPE:  Character  WIDTH:  16 

The  description  of  each  interoperability  code. 


DATABASE:  CROB21 


DESCRIPTION:  This  database  describes  each  activity  code  used  in  CDB. 


Act code  TYPE:  Character  WIDTH:  1 

An  activity  code. 

Descript  TYPE:  Character  WIDTH;  37 

The  description  of  the  activity. 


DATABASE:  CROB22 


DESCRIPTION:  This  database  describes  each  perishability  code  used  in  CDB. 


Sos code  TYPE;  Character  WIDTH;  2 

A  perishability  code. 

Descript  TYPE:  Character  WIDTH:  9 

The  description  of  each  perishability  code. 
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DATABASE;  CROB23 


ki 


DESCRIPTION:  This  database  describes  each  Cost  Of  Failure  code  used  in  COB. 


Cof code  TYPE:  Charaaer  WIDTH;  1 

The  cost  of  failure  codes. 

Oescript  TYPE:  Charaaer  WIDTH;  13 

The  description  of  each  cost  of  failure  code. 


DATABASE;  CRDB24 

DESCRIPTION;  This  database  describes  each  echelon  code  used  in  CD6. 

Ech_code  TYPE;  Charaaer  WIDTH:  1 

An  echelon  code. 

Oescript  TYPE;  Charaaer  WIDTH;  54 

The  description  of  each  echelon  code. 


DATABASE:  CROB25 

DESCRIPTION;  This  database  describes  each  proponent  code  used  in  CDB 

Prop_code  TYPE;  Char<Kt«r  WIDT!-I:  1 

A  proponent  cede. 

Descript  TYPE:  Cheraaef  WIDTH:  55 

The  de.  tnption  of  the  proponent  code.  i 

.  i  ■ 

DATABASE:  CRDB26 

DESCRIPTION:  This  database  describes  the  intensity  of  battle  codes  used  in  COB. 

Inten _ code  TYPE:  Charaaer  WIDTH:  1 

An  intensity  code. 

Oescript  TYPE:  Charaaer  WIDTH;  10 

The  description  of  the  intensity  code. 


A-12 


DATABASE;  CRDB27 


DESCRIPTION:  This  database  describes  each  equipment  code  used  in  CDB. 


Equip code  TYPE:  Character  WIDTH:  2 

An  equipment  code. 

Oescript  TYPE:  Character  WIDTH:  48 

The  description  of  the  equipment  code. 


DATABASE:  CRDB28 


DESCRIPTION;  This  database  describes  each  traffic  classification  code  used  in  CDB. 


Tclas code  TYPE:  Character  WIDTH:  1 

A  code  for  the  classification  of  the  traffic  expressed  in  the 
needline. 

Oescript  TYPE:  Character  WIDTH:  18 

The  description  of  the  traffic  classification  code. 


DATABASE:  CRO630 

DESCRIPTION:  This  database  describes  each  data  device  code  used  in  CDB. 

Dd_code  TYPE:  Character  WIDTH:  1 

A  data  device  code. 

Oescript  TYPE:  Character  WIDTH:  8 

The  description  of  the  data  device  code. 
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DATABASE:  CRDB40 


DESCRIPTION;  This  database  describes  each  line  item  number  (LIN)  and  its 
nomenclature.  Also,  the  LIN  is  associated  with  specific  equipment  codes  based  on 
.the  system  capabilities  of  the  item. 


Lin 

Nomen 

Phone 

Tty 

Facs 

Vhf^fm 

Hf _ voice 

Msrt 

Uhf _ fm 

Uhf _ am 

Hr _ ratt 

Tacfire 

Das_3 

Taccs 

Ulcs 

Mcs 


TYPE;  Character  WIDTH:  1 

The  Line  Item  Number  of  the  equipment. 

TYPE:  Character  WIDTH:  54 

The  nomenclature  of  the  equipment. 

TYPE:  Numeric  WIDTH;  1.0 

The  quantity  of  phone  capabilities. 

TYPE:  Numeric  WIDTH:  1.0 

The  quantity  of  teletype  capabilities. 

TYPE:  Numeric  WIDTH:  1.0 

The  quantity  of  facsimile  capabilities. 

TYPE;  Numeric  WIDTH:  1.0 

The  quantity  of  VHF  FM  capabilities. 

TYPE.  Numeric  WIDTH:  1.0 

The  quantity  of  HF  VOICE  capabilities. 

TYPE;  Numeric  WIDTH:  1.0 

The  quantity  of  MSRT  capabilities. 

TYPE:  Numeric  WIDTH.  1.0 

The  quantity  of  UHF  FM  capabilities. 

TYPE:  Numeric  WIDTH:  1.0 

The  quantity  of  UHF  AM  capabilities. 

TYPE:  Numeric  WIDTH:  1.0 

The  quantity  of  HF  RATT  capabilities. 

TYPE.  Numeric  WIDTH:  1.0 

The  quantity  of  TACFIRE  d^ta  device  capabilities. 

TYPE;  Numeric  WIDTH:  1.0 

The  quantity  of  DAS3  data  device  capabilities. 

TYPE:  Numeric  WIDTH;  1.0 

The  quantity  of  TACCS  data  device  capabilities. 

TYPE;  Numeric  WIDTH:  1.0 

The  quantity  of  ULCS  data  device  capabilities. 

TYPE;  Numeric  WIDTH:  1.0 

The  quantity  of  MCS  data  device  capabilities. 
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DATABASE;  CRDB41 


CLSCRIPTION:  This  database  represents  the  communication  equipment  found  in  a 
SRC. 


SRC  TYPE:  Charaaer  WIDTH;  9 

The  standard  requirements  code  of  the  unit. 

Para  TYPE;  Chararter  WIDTH:  2 

The  paragraph  within  the  unit  where  some  equipment  is 
located. 

Lin  TYPE:  Chararter  WIDTH:  6 

The  Line  Item  Number  of  the  equipment. 

Qty  TYPE:  Numeric  WIDTH;  3.0 

The  quantity  of  the  specific  LIN  found  in  a  paragraph. 


DATABASE:  CROB42 


DESCRIPTION:  This  database  summarizes  the  equipment  capabilities  for  each 
paragraph  of  each  SRC  and  for  each  SRC.  Each  record  with  a  non-zero  paragraph 
number  represents  the  capabilities  of  the  specific  paragraph.  Each  record  with  a 
paragraph  number  equal  to  zero  represents  the  total  capability  of  the  entire  SRC. 

Src  TYPE;  Chararter  WIDTH:  9 

The  standard  requirements  code  of  the  unit. 

Para  TYPE:  Chararter  WIDTH;  2 

The  paragraph  within  the  unit. 

Lin  TYPE;  Character  WIDTH.  6 

The  Line  Item  Number  of  the  equipment. 


Phone  TYPE:  Numeric  WIDTH:  3.0 

The  quantity  of  phone  capabilities. 

Tty  TYPE:  Numeric  WIDTH:  3.0 

The  quantity  of  teletype  capabilities. 

Facs  TYPE:  Numeric  WIDTH;  3.0 

The  quantity  of  facsimile  capabilities. 

Vhf__fm  TYPE:  Numeric  WIDTH:  3.0 

The  quantity  of  VHF  FM  capabilities. 

Hf _ voice  TYPE;  Numeric  WIDTH:  3.0 

The  quantity  of  HF  VOICE  capabilities. 
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DATABASE;  CR0842  (Cont.) 


Msrt 

Uhf _ fm 

Uhf__am 

Vhf _ am 

Hf _ ratt 

Tacfire 

0as__3 

Taccs 

Ulcs 

MC5 


TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  MSRT  capabilities. 

TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  UHF  FM  capabilities. 

TYPE;  Numeric  WIDTH.  3.0 

The  quantity  of  UHF  AM  capabilities. 

TYPE.  Numeric  WIDTH;  3.0 

The  quantity  of  VHF  AM  capabilities. 

TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  HF  RATT  capabilities. 

TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  TACFIRE  data  device  capabilities. 

TYPE;  Numeric  WIDTH.  3.0 

The  quantity  of  DAS3  data  device  capabilities. 

TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  TACCS  data  device  capabilities. 

TYPE;  Numeric  WIDTH;  3.0 

The  quantity  of  ULCS  data  device  capabilities. 

TYPE;  Numeric  WIDTH:  3.0 

The  quantity  of  MCS  data  device  capabilities. 
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II.  DATABASE  RELATIONSHIPS 


One  advantage  of  a  relational  database  management  system  is  the  space 
saved  by  not  repeating  the  same  data  for  every  record  in  a  database.  A  good 
example  of  this  is  the  method  of  storing  the  communicators  represented  by  every 
needline.  The  aaual  communicator  code  is  not  part  of  the  needline  itself.  Instead, 
another  database  associates  every  possible  person  from  every  SRC  with  a 
communicator  code.  There  are  over  22,000  possible  communicators,  but  relating 
this  database  and  the  needline  database  together  to  obtain  the  communicator  code 
for  both  the  needline  originator  and  receiver  is  desirable  over  including  both 
communicator  codes  on  more  than  300,000  needlines.  The  primary  database 
relationships  are  shown  in  Figure  A-2.  The  principal  fields  from  each  database  are 
listed  inside  the  box.  A  line  connecting  two  databases  indicates  that  a  relationship 
exists.  A  relationship  requires  common  data  from  each  database.  This  data 
constitutes  the  key  of  the  relationship.  The  key  can  be  part  of  a  field,  an  entire 
field,  or  multiple  fields.  The  field(s)  comprising  the  key  from  each  database  are 
listed  below  the  second  database.  When  two  databases  can  be  related  on  more 
than  one  key,  each  key  is  listed. 
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Src 

Para 

Line  Fake  para 

Fake  line 

Grade 

Position 

Mo« 

Multiplier 

Zone 

Comm  code 

1  CR0809  _ 

Src  Para  Saction 


Org _ ire 

<•> 

Src 

Org_pafa 

<•> 

Para 

Org__line 

<•> 
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R£¥r_»fC 

<-> 

Src 

Rtvr_para 

<-> 

Para 

Rc»r _ line 

<•> 

Line 

Or9_irt 

<-> 

Src 

Or9_para 

<-> 

rake_para 

Ofg_line 

<*> 

rake _ line 

fl<vr_»f< 

<-> 

Src 

RC¥r_para 

<•> 

Faka_para 

Rt«r_iine 

<-> 

Fake_line 

Src 

<-> 

Src 

Para 

<-> 

Para 

Src 

<-> 

Src 

Fake _ para 
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I  CROB08 
I  Comm _ code  Title 

•  Comm_£Od#  <•>  Comm _ code 

.CR0814 

Zone  code  Detcript 
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Src 
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Src 
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FIGURE  A-2.  COB  Database  Relationships  ( 1  of  2). 
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FIGURE  A-2.  CD6  Database  Relationships  (2  of  2). 
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INTRODUCTION 

The  Communications  Data  Base  (CDB)  is  a  database  which 
represents  communications  requirements  of  selected 
organizations.  Organizations  represented  in  the  COB  are 
identifiable  by  Standard  Requirements  Code  (SRC)  Number 
where  SRC  data  is  available  for  units.  In  cases  where  SRC 
data  does  not  exist  (NATO,  Joint  Services,  etc.)  pseudo-SRCs 
are  developed  to  allow  for  the  description  of  communications 
requirements  into  and  out  of  these  units.  In  all  cases  SRCs 
chosen  for  CDB  use  represent  the  most  current  approved 
version  (Series)  available  at  the  time  SRCs  are  chosen. 

Communications  requirements  within  the  CDB  are  depicted 
in  terms  of  Needlines.  A  Needline  is  a  series  of  related 
data  elements  which  describe  a  requirement  to  communicate 
information  between  two  or  more  battlefield  communicators.  A 
Needline  describes  the  originator  and  receiver  of  the 
communications  (identified  by  SRC,  Paragraph  and  Line),  the 
reason  for  the  communications  requirement  (Purpose  and 
Function),  the  subject  of  the  call  (Message),  the  length  of 
the  message,  the  number  of  times  per  day  the  message  is 
sent,  the  importance  and  perishability  of  the  information, 
and  a  number  of  other  descriptors  of  the  communications 
requirement. 

The  CDB  has  been  developed  by  the  Sign"  -  -  to  be 

used  as  an  analytical  tool  :  n  conjunction  .»•.  LrTAC 

Data  Base  and  the  Network  Assessment  Model.  r.  operative 

use  of  these  three  tools  will  allow  the  5:  ,  lo?  er  ter  to 
assess  the  capability  of  various  common  i  cat  . 
architectures  to  accommodate  battlefield  iriformation 
exchange  requirements  for  many  different  force  structure 
arrays,  using  standard  and  non-standard  deployment  schemes, 
over  a  range  of  geographic  deployment  locations. 

<r.P  initial  set  of  CDB  needline  data  was  developed 
1906-1987.  This  data  was  verified  by  Proponent  Centers  and 
Schools  during  the  summer  of  1907  and  was  validated  by  the 
Combined  Arms  Center  in  November  1987.  This  initial  set  of 
data  represented  a  sat  of  SRCs  which  would  normally  be 
assigned  and  deployed  forward  of  a  Corps  rear  boundary.  A 
skeletal  Echelons  Above  Corps  (EAC>  force  was  developed  and 
used  for  this  initial  effort. 

The  current  CDB  effort  was  aimed  at  EAC.  During  the 
current  phase  (which  began  in  March  1988)  a  set  of  SRCs  was 
chosen  to  represent  a  group  of  units  which  would  normally  be 
assigned  to  a  force  operating  at  EAC.  You  have  not  yec  seen 
the  needlines  developed  for  this  EAC  force,  but  are  now 
being  provided  them  for  your  initial  verification.  Your 
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task  is  two-^old.  First,  to  re-veri'fy  those  needlines  that 
were  developed  for  the  initial  CDB  and  were  previously 
verified  by  your  Center  in  1987.  These  needlines  were 
provided  to  you  in  October  19B6  and  you  have  been  reviewing 
them  for  the  last  several  weeks*  Your  second  task  is  to 
conduct  your  initial  verification  review  of  the  new  (EAC) 
needlines  which  have  been  developed  during  the  current  COB 
phase. 

Both  sets  of  needlines  (those  being  re^verified  and 
those  being  initially  verified)  are  contained  on  the  data 
diskettes  you  have  been  provided.  Verification  Software  has 
been  developed  for  your  use  which  will  allow  you  to  conduct 
all  verification  actions  simultaneously.  When  you  are 
finished,  you  will  have  completed  all  verification  actions 
necessary  for  the  CDB  this  year.  You  will  be  kept  informed 
of  CDB  actions  planned  for  nw^it  year. 

The  CDB  is  a  "living"  data  base  which  will  require 
continuing  monitoring,  expansion  and  change  as  the  Army 
continues  to  change  SRC  organizations  and  introduces  newer 
generations  of  communications  and  automation  devices  and 
systems  to  improve  battlefield  information  flow.  Your 
continued  support  of  the  Communications  Data  Base  efforts  is 
vital  and  appreciated. 
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FOREWORD 

This  COB  NEEDLINE  CODEBOOK  AND  USER'S  GUIDE  FOR 
PROPONENT  VERIFICATION  was  davaloped  to  assist  Proponant 
Project  Officers  during  Proponent  Verification  of  the 
Communications  Data  Base.  The  CODEBOOK  provides  an 
eKplanation  of  those  CDB  needline  elements  you  will  see  when 
using  the  Proponent  Verification  Software  and/or  when 
reviewing  needline  printouts  for  your  SRCs.  Every  effort  has 
been  made  to  make  the  CODEBOOK  and  Software  both 
understandable  and  easy  to  use. 

We  recommend  you  adopt  the  following  methodology  in 
completing  your  verification  actions: 

1.  Familiarize  yourself  with  the  CDB  by  reading 
this  Needline  Codebook. 

2.  Load  your  Proponent  Verification  Software 
Installation  Diskettes  on  the  Personal  Computer  (PC)  you 
will  be  using  to  process  your  needlines.  The  PC  should  have 
at  least  6  Megabytes  of  available  hard  disk  space. 

3.  Print  copies  of  the  Communicator  Code  Dictionary 
(can  be  printed  in  either  alphabetic  or  numeric  sequence,  or 
both ) . 

4.  Print  a  copy  of  the  CDB  Message  Dictionary. 

5.  Using  your  SRC  data  diskettes,  print  the 
ncedlines  for  each  of  your  SRCs. 

6.  Using  your  SRC  data  diskettes,  print  the 
Personnel /Equi pment  listings  for  each  of  your  SRCs. 

7.  Using  your  SRC  data  diskettes,  print  a 
Connectivity  Matrix  for  those  SRCs  for  which  you  would  like 
to  review  connectivity. 

8.  Review  needlines  for  each  of  your  SRCs  using  the 
needline  printouts,  and  using  the  other  printout  material 
for  reference  material. 

9.  Record  desired  needline  changes  (pen  and  ink)  on 
the  needline  printouts.  After  you  have  completed  the  pen 
and  ink  changes  on  the  needline  printouts,  use  them  to  enter 
changes  on  the  needline  data  diskettes  using  the  Proponent 
Verification  Software  previously  loaded  on  your  hard  disk. 

ALL  CHANGES  to  need lines  MUST  BE  entered  on  the  SRC 
diskettes  using  the  Proponent  Verification  Software  you  have 
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been  provided. 

DATA  NEEDLINE  NOTE: 

During  the  development  oi  the  CBD  we  have  attempted  to 
capture  DATA  needlines  which  can  be  supported  by  data 
devices  appearing  in  SRC  documentation.  Me  realize  that 
many  automated  systems  do  not  yet  appear  in  SRCs  but  are  in 
some  earlier  stage  in  the  developmental  process.  It  has  long 
been  our  intention  to  incorporate  Battle'field  Automated 
Systems  into  the  CDB  as  these  systems  evolved. 

The  Proponent  Ver i -f icati on  Software  we  have  developed 
allows  you  to  indicate  those  needlines  which,  although  not 
presently  siipported  in  SRCs  with  automated  equipment,  will 
eventually  be  supported  with  such  equipment.  The  software 
will  prompt  you  to  answer  a  set  of  questions  regarding 
planned  data  systems,  message  lengths,  etc..  This  process 
will  be  explained  in  detail  at  the  verification  kick**off 
meeting  in  early  November. 

As  you  complete  your  COB  verification,  should  you  have 
any  questions  regarding  the  software,  the  Codebook,  or  any 
other  CDB  related  issue  please  contact  the  Signal  Center 
Points  of  Contact: 

Mailing  CDR,  US  Army  Signal  Center 

Address  Attn:  ATZH-CDC 

<Mr.  Tracy  Mood/MAJ  William  Key) 

Fort  Gordon,  GA  30905-5090 

Telephone  AUTOVON  780-3782/3561 

COMMERCIAL  (404)  791-3782/3561 

Electronic  atzh_cdc_s3opentagon-opti .army.mil 

Mail 
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ACTIVITY 

TYPE;  Character  MIDTH:  1 

DESCRIPTION:  This  data  element  describes  the  enistence  o-f  a 

needline  that  applies  only  when  a  certain,  speci'fied 
activity  is  being  accomplished  by  the  communicator (s) .  For 
example,  a  needline  having  an  activity  code  oi  "N"  would 
apply  only  when  either  communicator  was  engaged  in  an  ”NBC 
OPERATIONS"  activity  in  accordance  with  a  particular 
scenario  event.  Most  needlines  carry  an  Activity  Code  of 
"Z"  which  means  that  the  needline  applies  regardless  of  any 
specific  activity  designation.  In  other  words,  a  "Z" 
Activity  Code  means  the  needline  always  applies.  Activity 
Codes  other  than  "Z"  are  additive  to  "Z"  needlines  and 
describe  additional  communications  requirements  associated 
with  the  performance  of  the  indicated  activity.  Activity 
Codes  and  their  descriptions  are  shown  below. 

CODE  and  DESCRIPTIONt 

A  -  ATTACK,  COUNTER  -  ATTACK,  RECONNDITER 

B  =  exploit,  pursue 

C  »  DEFEND,  DELAY,  SCREEN 
0  «  PASSAGE  (Moving),  RELIEVE 
E  >  PASSAGE  (Stationary),  RELIEVE 
F  *  MARCHING 
G  -  MOVING  TO  CONTACT 
H  »  COVERING  FORCE 
J  -  CLEARING  OBSTACLE  /  MINEFIELD 
K  >  CROSSING  MINEFIELD 
L  »  CROSSING  RIVER 
N  a  NBC  OPS 
R  »  RESERVE 

T  »  TACTICAL  MISSILE  DEFENSE 
Z  «  NEEDLINE  NOT  QUALIFIED  BY  ACTIVITY 


BROADCAST  GROUP 

TYPE:  Numeric  WIDTH:  4 

DESCRIPTION:  This  data  element  describes  a  group  of 

needXines  which  are  sent  by  a  single  originator, 
simultaneously,  to  a  group  of  receivers  using  communications 
means  which  lend  themselves  to  multiple  addressee 
transmissions  (eg.  Combat  Net  Radio,  MSE  conferencing 
capability,  etc.).  Broadcast  Groups  are  each  assigned  a  four 
digit  numeric  value  within  each  SRC.  Broadcast  Groups  0001 
thru  3000  were  reserved  for  Signal  Center  developmental 
purposes.  If  you  wish  to  create  Broadcast  Groups  for  your 
SRCs  you  should  use  numbers  3001  thru  9999  for  each  SRC. 
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COfiriUNICATGR  CODE  (Or._/RCVR) 

TYPE:  Character  WIDTH;  4 

DESCRIPTION:  This  data  elamant  describes  the  communicator 

(both  originator  and  receiver)  in  terms  of  the  code  assigned 
to  him  by  the  TBE  Analyst.  Communicator  Codes  were  developed 
as  an  attempt  to  standardize  SRC  Titles  for  communicators 
and  to  conserve  space  in  needline  records.  You  can  print  the 
complete  listing  of  Communicator  Codes  (in  either  alphabetic 
or  numeric  sequence)  by  using  the  Print  Utility  Software 
provided  in  your  Needline  Verification  Package. 

COST  OF  FAILURE  (COF) 

TYPE:  Character  WIDTH;  1 

DESCRIPTION:  This  data  element  describes  the  effect*  on  the 

ability  of  the  originator,  to  accomplish  his  mission,  if 
this  needine  is  not  satisfied.  Recognizing  all  CDB  needlines 
are  "iiission  Essential",  some  remain  more  important  than 
others.  This  data  element  is  intended  to  describe  their 
relative  importance.  An  "INDISPENSABLE"  needline  is  one 
which,  if  not  satisfied,  causes  complete  mission  failure  for 
the  originator.  A  "CRITICAL"  needline  is  one  which,  if  not 
satisfied  repeatedly  over  an  extended  period  of  time,  will 
cause  mission  failure  for  the  originator.  An  "ESSENTIAL" 
needline  is  one  which,  if  continually  not  satisfied,  over  an 
extended  period  of  time,  will  have  a  negative  impact  on  the 
ability  of  the  originator  to  accomplish  his  mission.  COST 
OF  FAILURE  codes  and  their  values  are  shown  below. 

CODE  and  DESCRIPTION! 

I  -  INDISPENSABLE 
C  »  CRITICAL 
E  -  ESSENTIAL 


DATA  DEVICE  (OR0/RCVR) 

TYPE:  Character  WIDTH:  3 

DESCRIPTION:  This  data  element  describes  the  data  terminal 

device  being  used  by  both  the  originator  and  receiver  to 
send  and  receive  the  message  represented  on  the  needline. 
These  fields  are  used  only  for  DATA  MODE  needlines  (all 
other  modes  will  carry  blanks  in  the  DATA  DEVICE  fields).  If 
you  find  a  non-data  mode  needline  which  you  believe  should 
be  a  data  mode  needlin*,  the  Verification  Software  will 
prompt  you  tn  provide  information  which  will  allow  us  to 
capture  your  requirements. 
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DATA  DEVICE  (ORG/RCVR)  (continued) 

CODE  «nd  DESCRIPTIONS 

001  -  TACFIRE 
002  «  DAS3 
003  «  FAAR 
ee4  s  TADARS 
005  «  PERSHING 
006  «  NET 
007  «  TACCS 
008  «  ULCS 
009  »  MCS 


EQUIPMENT  (PRIME  EQ,  8ECND  EQ> 

TYPES  Character  WIDTH:  2 

DESCRIPTIONS  This  data  alamant  dascrlbas  th«  aquipmant  that 
will  ba  usad  by  tha  originator  to  satisfy  tha  naadlina 
raqui ramant .  Each  naadlina  carrias  both  a  "Primary"  and  a 
"Sacondary"  aquipmant  coda.  Thasa  codas  simply  raprasant  tha 
originator’s  first  and  sacond  choicas,  raspacti val y,  for  tha 
typa  of  aquipmant  ha  will  usa  to  satisfy  tha  naadlina 
raquiramant.  Compatibla  aquipmant  must  ba  avai labia  to  both 
tha  originator  and  racaivar.  Tha  Varification  Softwara  will 
chack  to  insura  that  aquipmant  you  sal  act  is  both  available 
and  compatibla,  and  tha  softwara  will  help  you  make  tha 
right  choices.  In  soma  casas  you  may  faal  that  whila  tha 
desired  aquipmant  is  not  available  (at  either  tha  paragraph 
or  SRC  level)  it  would  actually  be  available  to  tha 
communicators  (perhaps  because  of  OPFAC  configurations,  or 
because  it  would  ba  provided  by  a  supporting  Signal  unit). 

In  these  casas  you  can  select  tha  appropriate  "60"  or  "70" 
series  equipment  as  provided  for  by  tha  softwara. 


CODE 

and  DESCRIPTION! 

00 

9 

NOTHING 

01 

m 

PHONE 

61 

91 

PHONE  « 

(in 

SRC,  not 

in  both  PARAs) 

71 

m 

PHONE  «* 

(not 

in  SRC, 

potentially 

avai 1  able) 

02 

m 

TTY 

72 

m 

TTY  $t 

(not 

in  SRC, 

potentially 

available) 

03 

m 

FACSIMILE 

73 

m 

FACSIMILE 

** (not 

in  SRC, 

potahti al 1 y 

aval  labia) 

04 

m 

VHF  FM 

64 

m 

VHF  FM  $ 

(in 

SRC,  not 

in  both  PARAs) 

74 

a 

VHF  FM  »» 

(not 

in  SRC, 

potential  1 y 

available) 

05 

9 

HF  VOICE 

65 

m 

HF  VOICE  * 

(in 

SRC,  not 

in  both  PARAs) 
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EQUIPMENT 

(PRIME  EQ, 

SECND 

EQ) 

(continued) 

75 

s 

HF  VOICE  »* 

(not 

in 

SRC, 

potent!  ally 

aval  1 abl e) 

68 

m 

MSRT 

68 

m 

MSRT  « 

(in  1 

SRC, 

not 

i n  both  PARP 

1  ) 

78 

m 

MSRT  tt 

(not 

i  n 

SRC, 

potential 1 y 

aval 1  able) 

SB 

m 

POUCH 

31 

a 

UHF  FM 

52 

a 

UHF  AM 

S3 

m 

VHF  AM 

54 

m 

HF  RATT 

FREQUENCY 

(MESSAGE) 

TYPE: 

Numer i c 

WIDTH* 

6 

DECIMAL: 

1 

DESCRIPTIONt  This  dsta  element  describes  the  number 
times,  per  24~hour  period,  the  message  identified  on  the 
needline  is  sent  between  the  originator  and  receiver. 

FUNCTION 

TYPE:  Character  WIDTH*  2 

DESCRIPTION*  This  data  element  describes  the  function, 
within  the  five  CDB  Purposes,  for  which  this  needline 
exists.  It  allows  a  further  level  of  specificity  in  the 
description  of  the  needline  requirement.  For  example,  a 
needline  carrying  a  PURPOSE  of  “2'*  and  a  FUNCTION  of  "66" 
would  be  a  needline  pertaining  to  ADMIN/PERSONNEL 
REPLACEMENTS.  FUNCTIONS,  with  their  appropriate  PURPOSE 
prefixes,  are  shown  below. 

CODE  and  DESCRIPTION! 

1  I  =  COMMAND/ INTER-UN IT 
166  »  COMMAND /INTRA-UN IT 

2  '  «  ADMIN/COORDINATION 
2  4  »  ADMIN/UCMJ 

2. 3  «  ADMIN/FINANCE 
2  6  -  ADM IN/ PERSONNEL  REPL 
2  7  »  ADMIN/MED  SPT  TREATMENT 
2  8  -  ADMIN/MED  SPT  EVAC 

2  9  -  ADMIN/CIVIL  AFFAIRS 
266  -  ADM IN/ INTRA-UN IT 

216  -  ADMIN/MILITARY  POl  ICE  SPT 

212  -  ADM IN/ CASUALTY  REPORT 

213  -  ADMIN/CHAPLAIN  SPT 

214  ■  ADM IN/ BRAVES  REGISTRATION 
213  -  ADMIN/POSTAL 

3  1  •  OPNS/COORDINATION 
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FUNCTION 

3  3 

S 

(continued) 

OPNS/LATERAL 

3  4 

■ 

OPNS/ENGINEER  SPT 

3  5 

m 

OPNS/COMMUNICATIONS  SPT 

3  6 

m 

OPNS/ADA  SPT 

3  7 

s 

OPNS/ artillery  SPT 

3  8 

m 

OPNS/AVIATION  SPT 

3  9 

m 

OPNS/ AIR  SPT 

360 

m 

OPNS/ INTRA-UN IT 

316 

9 

OPNS/CHEMICAL  SPT 

312 

a 

OPNS/ATC  INFO 

313 

a 

OPNS/EOD  SPT 

314 

a 

OPNS/ POS I T I ON-LOC AT I ON 

316 

a 

OPNS/ R AGO 

317 

a 

OPNS/MISSION  SPT 

319 

» 

QPNS/DPU  SPT 

4  1 

s 

INTEL/COORD INAT ION 

4  3 

a 

INTEL/LATERAL 

4  4 

« 

INTEL/SENSORS 

4  S 

a 

INTEL/SSO 

4  7 

s 

INTEL/ INTEL  REPORTS 

4  8 

a 

INTEL/ WEATHER 

466 

» 

INTEL/ INTRA-UN IT 

5  1 

a 

LOG/COOROINATION 

3  3 

a 

LOG/LATERAL 

3  4 

a 

LOG/RATION  RESUPPLY 

3  5 

a 

LOG/TOE  EQUIP  RESUPPLY 

3  6 

a 

LOG/POL  RESUPPLY 

3  7 

a 

LOG/ AMMO  RESUPPLY 

3  8 

a 

LOG/REPAIR  PARTS  RESUPPLY 

5  9 

a 

LOG/TRANSPORTATION  SPT 

366 

■ 

LOG/ INTRA-UNIT 

316 

» 

LOG/DS  MAINTENANCE 

311 

a 

LOG/GS  MAINTENANCE 

312 

• 

LOG/ BATH 

313 

a 

LOG/CLOTHING  RESUPPLY 

314 

s 

LOG/MED  EQUIP  RESUPPLY 

315 

a 

LOG/PKG  POL  RESUPPLY 

516 

a 

LOG/CHEM  EQUIP  RESUPPLY 

317 

a 

LOG/ENG  CNST  SUPPLY 

318 

a 

LOG/COMStC:  SUPPORT 

319 

a 

LOG/AIR  SUPPLY /RESUPPLY 

326 

a 

LOG/NUC  AMMO,  WEAPONS 

321 

a 

LOG/MISSILE  MAINTENANCE 

INTENSITY 

TYPEi  Character  WIDTHi  I 

DESCRIPTION:  This  data  element  describes  the  S'f'fect 
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INTENSITY  (continued) 

changes  in  levels  o-f  intensity,  with  which  the  originating 
unit  is  involved  in  performing  its  mission,  on  the  volume  of 
message  traffic  represented  on  the  needline.  An  assumption 
is  made  that  as  a  unit  gats  busier,  soma  types  of  traffic 
increase,  some  types  decrease,  and  some  types  stay  about  the 
same.  This  data  element  associates  each  needline  with  a 
volume/intensi ty  relationship  curve  which  will  allow  a  user 
of  the  data  base,  when  applying  needline  data  to  a  model,  to 
show  the  effects  of  intensity  on  traffic  volume,  by  varying 
message  frequency,  for  various  message  types. 

CODE  and  DESCRIPTION! 

D  «  DECREASING 
1  -  INCREASING 
S  -  STATIC 


INTEROPERAeiLITY 

TYPE*  Character  WIDTHi  1 

DESCRIPTION!  This  data  element  indicates  a  requirement,  or 
lack  thereof,  for  the  equipment  used  to  satisfy  this 
needline  requirement  to  EVER  have  the  need  to  interoperate 
with  non-US  Army  equipment  in  a  NATO  environment. 

CODE  and  DESCRIPTION! 

A  «  allied 
J  -  JOINT  f  ALLIED 
N  -  NO  REQUIREMENT 
0  -  OTHER  SERVICE 
S  -  OWN  SERVICE  ONLY 


LENGTH  (MESSAGE) 

TYPE!  Numeric  WIDTH!  6 

DESCRIPTION!  Tnis  data  element  describes  the  length  of  the 
message  being  sent  between  the  originator  and  receiver. 
Message  lengths  are  all  described  in  terms  of  characters. 
Recognizing  some  modes  of  transmission  are  more  aptly 
described  in  terms  other  than  characters  (eg.  voice  mode  - 
seconds/mi nutss)  the  following  conversion  factors  are  used 
for  CDS  purposes! 


3  characters 


1  word 
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LENGTH  (MESSAGE)  (continued) 

200  words  s  1000  char,  a  1/2  paqe  a  i  minute  oT  voice 
400  Words  a  2000  char,  a  i  page  *  2  minutes  o-f  voice 


NOTEi  It  is  not  necessary  to  enter  leading  zeros  (eg. 

000SS5  to  represent  SSS  characters).  The  so-ftware  will 
enter  them  automatically. 

LINE  (SRC)  (ORIGINATOR/ RECEIVER) 

TYPE:  Character  WIDTH;  2 

DESCRIPTION:  Tnis  data  element  describes  the  SRC  Line, 

within  a  paragraph,  to  which  the  originator  and  receiver  are 
assigned  in  their  respective  SRC  Document. 

NOTE:  You  must  enter  leading  zeros  in  this  field  (eg.  line 

"1"  must  be  entered  as  “01 “,  line  "10“  is  entered  as  "10", 
etc. ) 

MIMAOt  CLAM  IF  I  CAT  ION 

TYPE:  Character  WIDTH:  1 

DESCRIPTION:  This  data  element  is  intended  to  represent  the 

highest  level  of  classification  expected  for  the  traffic 
carried  on  the  needline.  It  refers  to  the  text  of  the 
message.  It  IS  NOT  used  to  indicate  the  existence  of  a 
needline  which  is  classified.  If  you  believe  you  have 
NEEDLINES  that  are  classified,  please  contact  the  Signal 
Center  Point  of  Contact  (POO. 

CODE  and  DESCRIPTION: 

U  •  UNCLASSIFIED 
C  -  CONFIDENTIAL 
S  -  SECRET 
T  -  TOP  SECRET 
3  -  CONFIDENTIAL  (SI) 
b  -  SECRET  (SI) 

7  •  TOP  SECRET  (SI) 

B  »  TOP  SECRET  (SI-TK) 


MESSAGE  CODE 

TYPE:  Character  WIDTH:  6 

DESCRIPTION:  This  data  element  describes  the  message  being 
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MESSAGE  CODE  (continued) 

sent,  -from  the  originator  to  the  receiver,  on  each  needline. 
You  can  print  a  comprehensive  listing  of  all  CDB  Message 
Codes,  their  titles  and  lengths,  by  using  the  Print  Utility 
Software  Provided  with  your  Verification  Package.  Messages 
used  in  the  CDB  were  provided  to  the  Signal  Center  by  CACDA 
and  represent  approved  USMTF  Messages  as  well  as  messages 
associated  with  the  TACPIPE  system.  A  sample  listing: 


MESSAGE 

MESSAGE 

MIN 

MAX 

CODE 

TITLE 

LENGTH 

LENGTH 

A023 

ENEMY  CONTACT  REPORT 

181 

6335 

A0SS 

PERSONNEL  REPORT 

200 

1200 

S014 

FRIENDLY  UNIT  STATUS 

200 

1400 

MOBILITY  (ORQ/RCVR) 

TYPE:  Character  WIDTH:  1 

This  data  element  describes  the  mobility  conditions,  for 
both  the  originator  and  the  receiver,  during  which  this 
needline  applies.  For  example,  a  needline  coded  with  a 
mobility  code  of  S  for  the  originator  would  indicate  that 
the  needline  only  applies  when  the  originator  is  stationary. 
Each  needline  carries  a  MOBILITY  code  for  both  the 
originator  and  receiver.  MOBILITY  codes  and  their  meanings 
are  shown  below. 


CODE  and  DESCRIPTION: 


A  «  Mobile  in  an  Aircraft 

F  »  Mobile  on  Foot 

M  »  Mobile  (any  manner) 

S  ■  Stationary 

T  a  Mobile  in  a  Tracked  Vehicle 

W  a  Mobile  in  a  Wheeled  Vehicle 

Z  a  A1 1  cases 


MODE 


TYPE:  Character  WIDTH:  1 


DESCRIPTION:  This  data  element  describes  the  desired  mode 

by  which  the  needline  should  be  satisfied.  Modes  are 
assigned  without  considering  equipment  available  to  the 
communicators.  For  example,  if  you  believe  a  Company 
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MODE  (contlnuad) 

Commander  in  one  o-f  your  SRCs  would  send  a  Spot  Report  to 
his  Battalion  Commander  usin^  a  VOICE  device*  you  should 
insure  that  such  a  needline  exists  (either  already  created 
or  you  create  yourself).  MODE  codes  are  shown  below. 

CODE  and  DESCRIPTIONS 

V  ■  VOICE 
P  »  PAGE 
D  =»  DATA 
F  =  FACSIMILE 
C  «  COURIER 


MULTIPLIER  (ORIGINATOR /RECEIVER) 

TYPE:  Numeric  WIDTH:  2 

DESCRIPTION:  This  data  element  describes  the  number 
(quantity)  of  both  originators  and  receivers  that  are 
reflected  in  the  SRC  Paragraph*  and  Line  in  their  respective 
SRC  Document. 

NOTE:  These  values  are  drawn  directly  from  your  SRC  and 

cannot  be  changed. 

NEEDLINE  SEQUENCE  (NDLN  SEQ) 

TYPE:  Numeric  WIDTH;  6 

DESCRIPTION:  This  data  element  provides  a  unique  reference 

number  for  each  needline.  Needline  Sequence  numbers  DO  NOT 
appear  in  any  particular  order  for  any  SRC*  but  they  DO 
provide  a  unique  reference  for  identifying  and  referencing 
each  individual  neadline  within  the  data  base.  You  cannot 
change  Needline  Sequence  Numbers  nor  should  you  try  to 
assign  one  for  a  needline  you  are  adding.  The  Verification 
Software  will  automatically  assirin/de  ^te  and  track  Needline 
Sequence  Numbers. 

PARAGRAPH  (SRC) (0R6/RCVR) 

TYPE;  Character  WIDTH;  2 

DESCRIPTION:  This  data  element  describes  the  SRC  Paragraph 

to  which  the  originator  and  receiver  are  assigned  in  their 
respective  SRC  Document. 

NOTE:  You  must  enter  leading  zeros  in  this  field  (eg. 

paragraph  "1"  must  be  entered  as  "12)1"*  paragraph  "10"  must 
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PARAGRAPH  (SRC) (ORG/RCVR)  (continued) 
be  entered  as  "10",  etc.). 

PERISHABILITY 

TYPE:  Character  WIDTH:  1 

DESCRIPTION:  This  data  element  describes  the  amount  of 

time,  from  the  perspective  of  the  originator,  that  can  be 
allowed  to  elapse  from  the  time  he  sends  his  message  until 
the  intended  receiver (s)  receives  it.  It  is  not  intended  to 
be  a  measure  of  capability,  but  rather  of  need,  as  viewed 
from  the  perspective  of  the  originator.  PERISHABILITY  codes 
and  their  associate  '  time-frames  are  shown  below. 

CODE  and  DESCRIPTION: 

0s  >  a  HRS 

1  »  4-0  HRS 

2  s  3-4  HRS 

3  *  2-3  HRS 

4  s  1-2  HRS 

5  »  10-60  MIN 

6  »  1-10  MIN 

7  *  23-39  SEC 

8  -  11-24  SEC 

9s  3-10  SEC 
A  »  1-4  SEC 

B  s  <1  SEC 


PURPOSE 

TYPE:  Character  WIDTH:  1 

DESCRIPTION:  This  data  element  describes  the  purpose  for 

which  this  needline  SKists.  The  PURPOSE  Code,  together  with 
FUNCTION,  acts  to  describe  the  reason  for  the  existence  of 
the  needline.  (Remember  -  a  needline  is  intended  to 
represent  a  Mission  Essential  NEED  to  communicate;  Not 
necessarily  a  CAPABILITY) 

VALUE  DESCRIPTION 

1  COMMAND 

2  administration 

3  OPEhATIONS 

4  INTELLIGENCE 

5  LOGISTICS 
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STANDARD  REQUIREMENTS  CODE  (SRC) 

TYPE:  Character  WIDTH:  9 

DESCRIPTION:  This  data  element  identifies  the  SRC  of  the 

originator  and  the  SRC  of  the  receiver  for  each  needline. 
The  Verification  Software  will  show  you  the  SRC  Number  anb 
the  SRC  Name  for  both  the  Originator  and  Receiver  on  each 
needl i ne. 

SUBSET  RATIO 

TYPE:  Character  WIDTH:  4 

DESCRIPTION:  This  data  element  describes  the  number  of 

originators  and  the  number  of  receivers  represented  on  the 
needline.  That  is,  how  many  originators  are  talking  to  how 
many  receivers?  The  first  two  positions  of  this  field 
represent  the  originator,  the  last  two  positions  represent 
the  receiver.  Por  example,  if  a  needline  is  intended  to 
represent  a  message  being  sent  by  one  Platoon  Leader  to 
three  Squad  Leaders,  the  SUBSET  RATIO  would  be  shown  as 
_1_3. 

UNIT  RELATIONSHIP  CODE  (URC) 

TYPE:  Character  WIDTH:  2 

DESCRIPTION:  This  data  element  describes  the  relationship 

between  the  SRC  of  the  originator  and  the  SRC  of  the 
receiver. 

CODE  and  DESCRIPTION: 

08  s  INTRA  (within  the  same  unit) 

AA  =  CO  to  CO  (same  BN) 

A0  =  Lower  to  Higher  in  Command  Chain 
8A  *  Higher  to  Lower  in  Command  Chain 
BP  »  Other  SVC  to  Host  Nation  (Civil) 

PB  *  Host  Nation  (Civil)  to  Other  SVC 
BT  «  US  Army  Unit  to  NATO  Military 
TB  *  NATO  Military  to  US  Army  Unit 

C0  ■  Direct  Support  to  Supported  (ADA,  ARTY  b  ENG  spt) 

0C  »  Supported  to  Direct  Support  (ADA,  ARTY  b  ENG  spt) 

00  ■  General  Support  to  Supported  (ADA,  ARTY  b  ENG  spt) 

OD  •  Supported  to  General  Support  (ADA,  ARTY  b  ENG  spt) 

F0  ■  GSR  unit  to  reinforced  unit 
0F  ■  Reinforced  unit  to  GSR  unit 
68  ■  Area  Support  to  Supported 
00  »  Supported  to  Area  Support 

JK  ■  Theater  (Army)  Unit  to  Host  Nation  (Civil) 

KJ  ■  Host  Nation  to  Theater  (Civil) 
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UNIT  RELATIUNSHIP  CCDE  (URC)  (continued) 

LL  =  CO  to  CO  (dlTTerent  BN  -  same  BDE) 

LM  -  Adjacent  US  DIV/CORPS  unit  to  DI'. .'CORPS  unit 
ML  a  DIV/CORPS  unit  to  Adjacent  US  DIV/CORPS  unit 
L.P  a  Host  Nation  unit  to  CORPS  unit 
PL  a  CORPS  unit  to  Host  Nation  unit 

MN  a  DIV/CORPS  unit  to  Adjacent  Allied  DIV/CORPS  unit 

NM  a  Adjacent  Allied  OIV/CORPS  unit  to  DIV/CORPS  unit 

MP  a  Corps  to  Theater 

PM  a  Theater  to  Corps 

NP  a  other  SVC  unit  to  US  Army  unit 

PN  a  US  Army  unit  to  other  SVC  unit 

PP  a  Other  SVC  to  Other  SVC 

RP  a  CO  to  CO  (di^T  BN,  BDE,  -  same  DIV) 

ST  a  Other  SVC  to  NATO  Military 

TS  a  NATO  Military  to  Other  SVC 

TT  a  NATO  Military  to  NATO  Military 

UU  a  CO  to  CO  (diff  BN,  BDE,  DIV,  -  same  CORPS) 

XZ  a  NATO  to  Host  Nation  Civil  Govt 
ZX  a  host  Nation  Civil  Govt  to  NATO 
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